Whitespace before responses

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Whitespace before responses

Mark Nottingham-2
<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:

   In the interest of robustness, servers SHOULD ignore at least one
   empty line received where a Request-Line is expected.  In other
   words, if the server is reading the protocol stream at the beginning
   of a message and receives a CRLF first, it SHOULD ignore the CRLF.

Should a similar approach be taken when clients parse responses?

See also:
  https://bugzilla.mozilla.org/show_bug.cgi?id=668168

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Willy Tarreau-3
On Thu, Jun 30, 2011 at 09:12:49AM +1000, Mark Nottingham wrote:
> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:
>
>    In the interest of robustness, servers SHOULD ignore at least one
>    empty line received where a Request-Line is expected.  In other
>    words, if the server is reading the protocol stream at the beginning
>    of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>
> Should a similar approach be taken when clients parse responses?

While I have done it in haproxy, I don't think it really adds any value,
as I don't remember having even seen a server emit extra CRLFs after a
response.

That said, skipping leading CRLFs can be quite cheap but can bring a new
issue for browsers who try to detect HTTP/0.9 responses.

Probably that we should check if any client implementation supports it
first, and decide not to take this approach if nobody does it right now ?

> See also:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=668168

Well, to be fair, I don't really catch the relation between this and
packet boundaries as discussed in this bug report. In my opinion, those
are two orthogonal things.

Regards,
Willy


Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Mark Nottingham-2

On 30/06/2011, at 9:34 AM, Willy Tarreau wrote:
> That said, skipping leading CRLFs can be quite cheap but can bring a new
> issue for browsers who try to detect HTTP/0.9 responses.

We've deprecated HTTP/0.9, so while it still might be encountered in the wild, implementations aren't required to support it, and we shouldn't prioritise its operation over good behaviour in HTTP/1.x.


> Probably that we should check if any client implementation supports it
> first, and decide not to take this approach if nobody does it right now ?

See the Moz bug; as I read it, they already support it if the response isn't fragmented.


>> See also:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=668168
>
> Well, to be fair, I don't really catch the relation between this and
> packet boundaries as discussed in this bug report. In my opinion, those
> are two orthogonal things.


Re-read :)


--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Willy Tarreau-3
On Thu, Jun 30, 2011 at 10:28:55AM +1000, Mark Nottingham wrote:
>
> On 30/06/2011, at 9:34 AM, Willy Tarreau wrote:
> > That said, skipping leading CRLFs can be quite cheap but can bring a new
> > issue for browsers who try to detect HTTP/0.9 responses.
>
> We've deprecated HTTP/0.9, so while it still might be encountered in the wild, implementations aren't required to support it, and we shouldn't prioritise its operation over good behaviour in HTTP/1.x.

I totally agree on this. After all, it's not even possible to retrieve a
file beginning with "HTTP/1." over HTTP/0.9, and it might even be dangerous.
So why support it as a fall-back at all ?

> > Probably that we should check if any client implementation supports it
> > first, and decide not to take this approach if nobody does it right now ?
>
> See the Moz bug; as I read it, they already support it if the response isn't fragmented.

This is a bug or a design error in my opinion. No assumption should be made
about how data are received over a TCP connection. The response should be
interpreted exactly the same if it comes one byte at a time or if it comes
as a single block. Even after re-reading it, I still don't get why there
are two possible interpretations depending on this.

In my opinion, either the UA accepts CRLFs before a response and should
skip all leading CRLFs until there is something different, or it does
not accept them and should not do that in only one case. We cannot rely
on isolated bytes from a partial stream to decide which version is being
reported. Otherwise I suppose that we can have the same breakage if
"HTTP/1.1" is sent one byte at a time, and this is wrong.

Regards,
Willy


Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Daniel Stenberg
In reply to this post by Mark Nottingham-2
On Thu, 30 Jun 2011, Mark Nottingham wrote:

>   In the interest of robustness, servers SHOULD ignore at least one
>   empty line received where a Request-Line is expected.  In other
>   words, if the server is reading the protocol stream at the beginning
>   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>
> Should a similar approach be taken when clients parse responses?

I don't think so. I don't think HTTP has allowed this and I don't think we
should soften this area now. I also have never gotten or seen a report similar
to the Firefox one so curl doesn't accept an initial CRLF in a HTTP response.

--

  / daniel.haxx.se

Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Bjoern Hoehrmann
In reply to this post by Mark Nottingham-2
* Mark Nottingham wrote:

><http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:
>
>   In the interest of robustness, servers SHOULD ignore at least one
>   empty line received where a Request-Line is expected.  In other
>   words, if the server is reading the protocol stream at the beginning
>   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>
>Should a similar approach be taken when clients parse responses?
>
>See also:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=668168

Well, we absolutely need to come to an agreement where messages start
and where they end. I would rather ask which behavior we are more like-
ly to agree on. Apart from that it's obviously best if nothing has to
be skipped, as skipping requires more work than not skipping.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Dale Anderson-8
In reply to this post by Mark Nottingham-2
Apologies, I put below message onto the wrong thread. Happy 4th of July, I knew something would blow up.. pow, there goes my email credibility!

Dale

2011/7/3 Dale Anderson <[hidden email]>:
> Hi Mark,
>
>> Should a similar approach be taken when clients parse responses?
>
> I think so, yes. Clients and servers should both ignore extra CRLF.
>
> Even if the client and the server are are both netcat/stdio the client
> or server at their station might want to hold down the enter button to
> make some clear room on their terminal.
>
> Similarly and with regards to your section 3.1, I like the way this
> first paragraph reads Mark then..
>
>>   Some old HTTP/1.0 client implementations send an extra CRLF after a
>>    POST request as a lame workaround for some early server applications
>>    that failed to read message-body content that was not terminated by a
>>    line-ending.  An HTTP/1.1 client MUST NOT preface or follow a request
>>    with an extra CRLF.  If terminating the request message-body with a
>>    line-ending is desired, then the client MUST include the terminating
>>    CRLF octets as part of the message-body length.
>
> I think the text reads better without giving the flawed example implementation.
>
> In the interest of robustness, client and server applications that are
> expecting to read a request or response line should not abjure all
> hope and connections if the line is empty (just CRLF). Try again, your
> request-line will come, don't abort this connection..
>
>
> Regards,
>
> Dale Anderson
>

Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Mark Nottingham-2
In reply to this post by Bjoern Hoehrmann
On 04/07/2011, at 6:56 AM, Bjoern Hoehrmann wrote:

> * Mark Nottingham wrote:
>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:
>>
>>  In the interest of robustness, servers SHOULD ignore at least one
>>  empty line received where a Request-Line is expected.  In other
>>  words, if the server is reading the protocol stream at the beginning
>>  of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>>
>> Should a similar approach be taken when clients parse responses?
>>
>> See also:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=668168
>
> Well, we absolutely need to come to an agreement where messages start
> and where they end. I would rather ask which behavior we are more like-
> ly to agree on. Apart from that it's obviously best if nothing has to
> be skipped, as skipping requires more work than not skipping.

From a quick test, Firefox and Chrome will skip at least two blank lines (without any whitespace on them); Opera will offer to download it as a file (!). Safari and Curl consider the whitespace and headers as the body (i.e., displaying it), as per HTTP/0.9. I don't have access to IE at the moment, but AIUI it'll operate as FF and Chrome.

Interestingly, Safari sniffs the response; if it looks like HTML, it will display it as such. I guess HTTP/0.9 by definition requires sniffing.

Cheers,

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

RE: Whitespace before responses

Eric Lawrence-4
If I recall correctly, some browsers apply different rules for leading whitespace/junk based on whether it's a top-level document or not.

IE (including IE9) are very liberal about ignoring unexpected junk preceding a HTTP response. For instance, IE will render bolded "Hello World" text when receiving this:


        This is not HTTP

       
        Is ItHTTP/1.1 200 OK
        Cache-Control: max-age=0
        Content-Type: text/html
        Connection: close

        <b>Hello world.</b>



In developing Fiddler, I ran across a few sites delivering HTTP/0.9 responses (e.g. without headers).  Here's an example: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=0&p=1&f=S&l=50&Query=IN%2FEric+Lawrence%0D%0A&d=PTXT which sends no headers, though it does lead the response with \n\n. It seems to render as a HTML document just fine in current versions of all major browsers.

-Eric

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Nottingham
Sent: Tuesday, July 05, 2011 4:57 PM
To: Bjoern Hoehrmann
Cc: httpbis Group
Subject: Re: Whitespace before responses

On 04/07/2011, at 6:56 AM, Bjoern Hoehrmann wrote:

> * Mark Nottingham wrote:
>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:
>>
>>  In the interest of robustness, servers SHOULD ignore at least one  
>> empty line received where a Request-Line is expected.  In other  
>> words, if the server is reading the protocol stream at the beginning  
>> of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>>
>> Should a similar approach be taken when clients parse responses?
>>
>> See also:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=668168
>
> Well, we absolutely need to come to an agreement where messages start
> and where they end. I would rather ask which behavior we are more
> like- ly to agree on. Apart from that it's obviously best if nothing
> has to be skipped, as skipping requires more work than not skipping.

>From a quick test, Firefox and Chrome will skip at least two blank lines (without any whitespace on them); Opera will offer to download it as a file (!). Safari and Curl consider the whitespace and headers as the body (i.e., displaying it), as per HTTP/0.9. I don't have access to IE at the moment, but AIUI it'll operate as FF and Chrome.

Interestingly, Safari sniffs the response; if it looks like HTML, it will display it as such. I guess HTTP/0.9 by definition requires sniffing.

Cheers,

--
Mark Nottingham   http://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Mark Nottingham-2
Current text:
"""
   In the interest of robustness, servers SHOULD ignore at least one
   empty line received where a Request-Line is expected.  In other
   words, if the server is reading the protocol stream at the beginning
   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
"""

Proposal:

"""
   In the interest of robustness, servers SHOULD ignore at least one
   empty line received where a Request-Line is expected.  In other
   words, if the server is reading the protocol stream at the beginning
   of a message and receives a CRLF first, it SHOULD ignore the CRLF.

   Likewise, clients SHOULD ignore at least one empty line received
   where a Status-Line is expected.

   Note that this relaxation does not apply to other characters; ignoring
   arbitrary non-whitespace characters before a message enables
   cross-protocol attacks.
"""



On 08/07/2011, at 6:08 AM, Eric Lawrence wrote:

> If I recall correctly, some browsers apply different rules for leading whitespace/junk based on whether it's a top-level document or not.
>
> IE (including IE9) are very liberal about ignoring unexpected junk preceding a HTTP response. For instance, IE will render bolded "Hello World" text when receiving this:
>
>
> This is not HTTP
>
>
> Is ItHTTP/1.1 200 OK
> Cache-Control: max-age=0
> Content-Type: text/html
> Connection: close
>
> <b>Hello world.</b>
>
>
>
> In developing Fiddler, I ran across a few sites delivering HTTP/0.9 responses (e.g. without headers).  Here's an example: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=0&p=1&f=S&l=50&Query=IN%2FEric+Lawrence%0D%0A&d=PTXT which sends no headers, though it does lead the response with \n\n. It seems to render as a HTML document just fine in current versions of all major browsers.
>
> -Eric
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Nottingham
> Sent: Tuesday, July 05, 2011 4:57 PM
> To: Bjoern Hoehrmann
> Cc: httpbis Group
> Subject: Re: Whitespace before responses
>
> On 04/07/2011, at 6:56 AM, Bjoern Hoehrmann wrote:
>
>> * Mark Nottingham wrote:
>>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.1> says:
>>>
>>> In the interest of robustness, servers SHOULD ignore at least one  
>>> empty line received where a Request-Line is expected.  In other  
>>> words, if the server is reading the protocol stream at the beginning  
>>> of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>>>
>>> Should a similar approach be taken when clients parse responses?
>>>
>>> See also:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=668168
>>
>> Well, we absolutely need to come to an agreement where messages start
>> and where they end. I would rather ask which behavior we are more
>> like- ly to agree on. Apart from that it's obviously best if nothing
>> has to be skipped, as skipping requires more work than not skipping.
>
>> From a quick test, Firefox and Chrome will skip at least two blank lines (without any whitespace on them); Opera will offer to download it as a file (!). Safari and Curl consider the whitespace and headers as the body (i.e., displaying it), as per HTTP/0.9. I don't have access to IE at the moment, but AIUI it'll operate as FF and Chrome.
>
> Interestingly, Safari sniffs the response; if it looks like HTML, it will display it as such. I guess HTTP/0.9 by definition requires sniffing.
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Roy T. Fielding
On Feb 7, 2012, at 4:53 PM, Mark Nottingham wrote:

> Current text:
> """
>   In the interest of robustness, servers SHOULD ignore at least one
>   empty line received where a Request-Line is expected.  In other
>   words, if the server is reading the protocol stream at the beginning
>   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
> """
>
> Proposal:
>
> """
>   In the interest of robustness, servers SHOULD ignore at least one
>   empty line received where a Request-Line is expected.  In other
>   words, if the server is reading the protocol stream at the beginning
>   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>
>   Likewise, clients SHOULD ignore at least one empty line received
>   where a Status-Line is expected.
>
>   Note that this relaxation does not apply to other characters; ignoring
>   arbitrary non-whitespace characters before a message enables
>   cross-protocol attacks.
> """

No, there is no need nor desire for such a relaxation.  The first rule is
to allow for backwards-compatible behavior with clients that send CRLF at
the end of a request without including it in the request message body count.
This new addition has no corresponding need.  IE is just handling a
message error, which is entirely dependent on the type of client being used.

....Roy

Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Mark Nottingham-2

On 08/02/2012, at 12:22 PM, Roy T. Fielding wrote:

> On Feb 7, 2012, at 4:53 PM, Mark Nottingham wrote:
>
>> Current text:
>> """
>>  In the interest of robustness, servers SHOULD ignore at least one
>>  empty line received where a Request-Line is expected.  In other
>>  words, if the server is reading the protocol stream at the beginning
>>  of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>> """
>>
>> Proposal:
>>
>> """
>>  In the interest of robustness, servers SHOULD ignore at least one
>>  empty line received where a Request-Line is expected.  In other
>>  words, if the server is reading the protocol stream at the beginning
>>  of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>>
>>  Likewise, clients SHOULD ignore at least one empty line received
>>  where a Status-Line is expected.
>>
>>  Note that this relaxation does not apply to other characters; ignoring
>>  arbitrary non-whitespace characters before a message enables
>>  cross-protocol attacks.
>> """
>
> No, there is no need nor desire for such a relaxation.  The first rule is
> to allow for backwards-compatible behavior with clients that send CRLF at
> the end of a request without including it in the request message body count.
> This new addition has no corresponding need.  IE is just handling a
> message error, which is entirely dependent on the type of client being used.

Yeah. I'm on the fence about this one; on the one hand, it's not a hard interop requirement, but on the other, pretty much every client does it, AFAICT.


--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Willy Tarreau-3
On Wed, Feb 08, 2012 at 12:25:34PM +1100, Mark Nottingham wrote:

>
> On 08/02/2012, at 12:22 PM, Roy T. Fielding wrote:
>
> > On Feb 7, 2012, at 4:53 PM, Mark Nottingham wrote:
> >
> >> Current text:
> >> """
> >>  In the interest of robustness, servers SHOULD ignore at least one
> >>  empty line received where a Request-Line is expected.  In other
> >>  words, if the server is reading the protocol stream at the beginning
> >>  of a message and receives a CRLF first, it SHOULD ignore the CRLF.
> >> """
> >>
> >> Proposal:
> >>
> >> """
> >>  In the interest of robustness, servers SHOULD ignore at least one
> >>  empty line received where a Request-Line is expected.  In other
> >>  words, if the server is reading the protocol stream at the beginning
> >>  of a message and receives a CRLF first, it SHOULD ignore the CRLF.
> >>
> >>  Likewise, clients SHOULD ignore at least one empty line received
> >>  where a Status-Line is expected.
> >>
> >>  Note that this relaxation does not apply to other characters; ignoring
> >>  arbitrary non-whitespace characters before a message enables
> >>  cross-protocol attacks.
> >> """
> >
> > No, there is no need nor desire for such a relaxation.  The first rule is
> > to allow for backwards-compatible behavior with clients that send CRLF at
> > the end of a request without including it in the request message body count.
> > This new addition has no corresponding need.  IE is just handling a
> > message error, which is entirely dependent on the type of client being used.
>
> Yeah. I'm on the fence about this one; on the one hand, it's not a hard
> interop requirement, but on the other, pretty much every client does it,
> AFAICT.

And probably that if they do it, it's because some old buggy servers used to
send this CRLF at the end of a response. Eg: a CGI script doing an "echo" after
"cat $file". I don't know how hard it would be to collect statistics on such
bad practices. We'd need to find a commonly deployed client which does not do
it and which confirms there's no issue when not accepting a CRLF in a response.

Willy


Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Amos Jeffries-2
On 8/02/2012 8:03 p.m., Willy Tarreau wrote:

> On Wed, Feb 08, 2012 at 12:25:34PM +1100, Mark Nottingham wrote:
>> On 08/02/2012, at 12:22 PM, Roy T. Fielding wrote:
>>
>>> On Feb 7, 2012, at 4:53 PM, Mark Nottingham wrote:
>>>
>>>> Current text:
>>>> """
>>>>   In the interest of robustness, servers SHOULD ignore at least one
>>>>   empty line received where a Request-Line is expected.  In other
>>>>   words, if the server is reading the protocol stream at the beginning
>>>>   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>>>> """
>>>>
>>>> Proposal:
>>>>
>>>> """
>>>>   In the interest of robustness, servers SHOULD ignore at least one
>>>>   empty line received where a Request-Line is expected.  In other
>>>>   words, if the server is reading the protocol stream at the beginning
>>>>   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
>>>>
>>>>   Likewise, clients SHOULD ignore at least one empty line received
>>>>   where a Status-Line is expected.
>>>>
>>>>   Note that this relaxation does not apply to other characters; ignoring
>>>>   arbitrary non-whitespace characters before a message enables
>>>>   cross-protocol attacks.
>>>> """
>>> No, there is no need nor desire for such a relaxation.  The first rule is
>>> to allow for backwards-compatible behavior with clients that send CRLF at
>>> the end of a request without including it in the request message body count.
>>> This new addition has no corresponding need.  IE is just handling a
>>> message error, which is entirely dependent on the type of client being used.
>> Yeah. I'm on the fence about this one; on the one hand, it's not a hard
>> interop requirement, but on the other, pretty much every client does it,
>> AFAICT.
> And probably that if they do it, it's because some old buggy servers used to
> send this CRLF at the end of a response. Eg: a CGI script doing an "echo" after
> "cat $file". I don't know how hard it would be to collect statistics on such
> bad practices. We'd need to find a commonly deployed client which does not do
> it and which confirms there's no issue when not accepting a CRLF in a response.
>
> Willy
>
>

Willy, the rest of the thread is about *request* not response. Squid has
not accepted response whitespace prefixes in a very long time and bug
reports about that are very rare.

Squid does skip whitespace at the beginning of the request and in my
recent experience it seems to be an active problem with scripts and
certain poular PDF readers.

AYJ

Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Willy Tarreau-3
Hi Amos,

On Thu, Feb 09, 2012 at 05:33:57PM +1300, Amos Jeffries wrote:
> Willy, the rest of the thread is about *request* not response.

No, look at the subject :-) The initial text covered only requests
and Mark asked if we should cover responses too.

> Squid has
> not accepted response whitespace prefixes in a very long time and bug
> reports about that are very rare.

Excellent ! In my opinion, Squid certainly qualifies as a reference for
something widely used. So if you don't have the issue, I think it means
the issue does not really exist, so we don't need to skip any CRLF before
a response.

> Squid does skip whitespace at the beginning of the request and in my
> recent experience it seems to be an active problem with scripts and
> certain poular PDF readers.

Same here. I've recently received a trace of a request emitted by a browser
announcing webkit in its UA, I believe it was Safari, where a POST request was
sent, then a few tens of milliseconds later, a CRLF was sent in a lone packet
while it was not part of the message-body. So I can confirm this is observed
from time to time. I'll see if I can find the capture so that we get the exact
UA, maybe it was old and has been fixed since.

Regards,
Willy


Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Amos Jeffries-2
On 9/02/2012 8:01 p.m., Willy Tarreau wrote:
> Hi Amos,
>
> On Thu, Feb 09, 2012 at 05:33:57PM +1300, Amos Jeffries wrote:
>> Willy, the rest of the thread is about *request* not response.
> No, look at the subject :-) The initial text covered only requests
> and Mark asked if we should cover responses too.

:-( /egg

>> Squid has
>> not accepted response whitespace prefixes in a very long time and bug
>> reports about that are very rare.
> Excellent ! In my opinion, Squid certainly qualifies as a reference for
> something widely used. So if you don't have the issue, I think it means
> the issue does not really exist, so we don't need to skip any CRLF before
> a response.

I suppose its also worth noting that the particular response code in
Squid is also violating the RFC by disallowing SP characters before the
"HTTP/1." string. With same lack of problems. It would be nice to drop
that requirement on the response line out of the spec if it is still there.

>
>> Squid does skip whitespace at the beginning of the request and in my
>> recent experience it seems to be an active problem with scripts and
>> certain poular PDF readers.
> Same here. I've recently received a trace of a request emitted by a browser
> announcing webkit in its UA, I believe it was Safari, where a POST request was
> sent, then a few tens of milliseconds later, a CRLF was sent in a lone packet
> while it was not part of the message-body. So I can confirm this is observed
> from time to time. I'll see if I can find the capture so that we get the exact
> UA, maybe it was old and has been fixed since.

Shockwave Flash has one report here
http://bugs.squid-cache.org/show_bug.cgi?id=2829. Not sure if that was
Flash itself or a badly coded app.

I only encountered PDF in help forum discussions, so no idea which is
was exactly.


AYJ

Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Willy Tarreau-3
On Fri, Feb 10, 2012 at 01:47:23AM +1300, Amos Jeffries wrote:
> I suppose its also worth noting that the particular response code in
> Squid is also violating the RFC by disallowing SP characters before the
> "HTTP/1." string. With same lack of problems. It would be nice to drop
> that requirement on the response line out of the spec if it is still there.

I have not seen this requirement in 2616. Haproxy doesn't allow this either.

Regards,
Willy


Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Patrick McManus-3
In reply to this post by Willy Tarreau-3
I definitely see whitespaces before responses now and again and tolerate
them as best as I can. Messing with that in a bis standardization update
seems to be an over reach. I find it hard to believe a document change
would change any deployed behavior (as it introduces breakage without
upside in a legacy protocol) - so the spec would just be less accurate
which is pretty much the opposite of the bis charter goal.

this embarrassing nit is, however, a good example of why http/2 needs to
be binary framed. Too much energy is expended on the commodity activity
of parsing headers the current way.




Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Willy Tarreau-3
On Thu, Feb 09, 2012 at 08:55:10AM -0500, Patrick McManus wrote:
> I definitely see whitespaces before responses now and again and tolerate
> them as best as I can. Messing with that in a bis standardization update
> seems to be an over reach.

OK, thanks for the feedback.

> I find it hard to believe a document change
> would change any deployed behavior (as it introduces breakage without
> upside in a legacy protocol) - so the spec would just be less accurate
> which is pretty much the opposite of the bis charter goal.

It's not that much a document change since it's already not allowed. Either
we acknowledge that a number of tools don't accept them and don't have any
issue and the text can remain as is, or we acknowledge that some implementers
had to relax the rule so we'd need to clarify this in the spec. Right now
you're saying that you had to implement something that is not covered by the
spec, and *this* is embarrassing. I must say I did this in haproxy without
realizing that the spec only allowed the leading CRLF in the request message.

> this embarrassing nit is, however, a good example of why http/2 needs to
> be binary framed. Too much energy is expended on the commodity activity
> of parsing headers the current way.

While binary framing can improve this, it is also much more complicate to
debug and test by hand. However strict fixed-length elements could be a
good improvement.

Regards,
Willy


Reply | Threaded
Open this post in threaded view
|

Re: Whitespace before responses

Zhong Yu
In reply to this post by Amos Jeffries-2
On Wed, Feb 8, 2012 at 10:33 PM, Amos Jeffries <[hidden email]> wrote:
> Squid does skip whitespace at the beginning of the request and in my recent
> experience it seems to be an active problem with scripts and certain poular
> PDF readers.

Do you mean arbitrary whitespaces before the request method, not just one CRLF?

Zhong

12