WebClient could keep an own buffer to simulate repeated streaming.

ByteArray contents would be more sensible in general.

As would be reading bytes from file streams by default, but somehow legacy
has left us with text streams as the default.

Are you willing to change the WebClient interface incompatibly to do the
right thing?

Also, does WebClient decode actual text correctly? For example, if the
server sends UTF-8 or -16 do we get the correct codepoints? Or do we get a
byte array of type ByteString?

Kind regards
Jakob

Tobias Pape <Das.Linux at gmx.de> schrieb am Fr., 13. Dez. 2019, 11:36:

>
> > On 13.12.2019, at 11:23, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> >
> > Hi, there!
> >
> > I can easily fetch some graphics from the Web:
> >
> > response := WebClient httpGet: '
> https://upload.wikimedia.org/wikipedia/en/e/ef/Commander_Keen_cover_art.jpeg
> '.
> >
> > However, the #content in this WebResponse is a ByteString even though
> the content-type is image/jpeg. I would expect the #content to be a
> ByteArray.
> >
> > content := response content.
> >
> > Because of this, I have to explicitely convert it before ImageReadWriter
> can work its magic:
> >
> > form := ImageReadWriter formFromStream: content asByteArray readStream.
> >
> > That's inconvenient. Maybe even a bug? Don't know.
> >
> > Best,
> > Marcel
> >
> > P.S.: Why doesn't SecureSocketStream respond to #reset? I cannot do this:
> >
> > ImageReadWriter formFromStream:
> >             (WebClient httpGet: '
> https://upload.wikimedia.org/wikipedia/en/e/ef/Commander_Keen_cover_art.jpeg
> ')
> >                          contentStream.
> >
>
>
> Simply because you cannot un-receive a network message.
> -t
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191214/cf32df1a/attachment.html>