- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 10 Feb 2012 01:47:23 +1300
- To: Willy Tarreau <w@1wt.eu>
- CC: ietf-http-wg@w3.org
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
Received on Thursday, 9 February 2012 12:47:56 UTC