W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Whitespace before responses

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 8 Feb 2012 11:53:36 +1100
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, httpbis Group <ietf-http-wg@w3.org>
Message-Id: <06CD470B-75A8-4152-9F39-F076A50556B5@mnot.net>
To: Eric Lawrence <ericlaw@exchange.microsoft.com>
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: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] 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/
Received on Wednesday, 8 February 2012 00:59:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:55 GMT