On Thu, May 7, 2020 at 9:11 PM Tobias Pape <Das.Linux at gmx.de> wrote:
>
>
> > On 07.05.2020, at 20:55, Beckmann, Tom <Tom.Beckmann at student.hpi.uni-potsdam.de> wrote:
> >
> > Ah I found the relevant part:
> > "   1.  Any response to a HEAD request and any response with a 1xx
> >       (Informational), 204 (No Content), or 304 (Not Modified) status
> >       code is always terminated by the first empty line after the
> >       header fields, regardless of the header fields present in the
> >       message, and thus cannot contain a message body."
> > - https://tools.ietf.org/html/rfc7230#section-3.3.3
> >
> > There appears to be no special cases for the remaining 3xx codes. In fact I believe I do remember seeing HTML content containing a link back in the days on some 301 pages.
> >
> > So could we change the line to
> >
> > (request method = 'HEAD' or: [(code between: 100 and: 199) or: [code = 204 or: [code = 304]]])
> >
> > when merging to trunk (and maybe include the reference to the RFC)? Or should I create a new commit to the inbox?
>
> New commit and then both to the trunk :)
> shipit ;)

+1

>
> -t
>
> >
> > Best,
> > Tom
> > ________________________________________
> > From: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> on behalf of Tobias Pape <Das.Linux at gmx.de>
> > Sent: Thursday, May 7, 2020 8:41:18 PM
> > To: The general-purpose Squeak developers list
> > Subject: Re: [squeak-dev] The Inbox: WebClient-Core-tobe.120.mcz
> >
> > Hi
> >> On 07.05.2020, at 20:24, Beckmann, Tom <Tom.Beckmann at student.hpi.uni-potsdam.de> wrote:
> >>
> >> Hey Tobi,
> >>
> >> we do still call `self content`, even if we go into the redirect branch, leading to the described timeout behavior:
> >>
> >> WebClient>>#sendRequest:contentBlock
> >> ...
> >>
> >>       "Handle redirect if needed"
> >>       (self allowRedirect and:[response isRedirect]) ifTrue:[
> >>               "Eat up the content of the previous response"
> >>               response content.
> >>               repeatRedirect := self redirect: request from: response.
> >>       ].
> >> ...
> >>
> >> I also felt like there should be a more general fix here. From what I read, if no content-length is given, the client should read data until the server closes the connection, however, the socket in SqueakSSL kept reporting that the socket was connected when I tried to fetch data from the GitHub API, until we timed out. This seemed like it would also constitute a correct (and also much simpler) fix, just that maybe we should make this list of codes where we do not need to read data even longer. Maybe I'm also missing another code path somewhere that should catch this case though.
> >
> > Yeah, in the end it is a robuster thing. Maybe we should catch all 3xx here? they ought all have no content, right?
> >
> > Best regards
> >        -Tobias
> >
> >
> >
>
>
>