- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 20 Jul 2012 09:08:08 +0200
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
On Fri, Jul 20, 2012 at 06:45:15PM +1200, Amos Jeffries wrote: > The key word in there is probably "browser", the assumption that each > client is singular ("browser") and that each connection is singular > ("user") is very widespread. > > That is no reason for any compliant server to disconnect. Let the broken > servers do it, and let the correct servers gain the benefits of being > correct. +1 on this. > Referring to this part specifically: "the server should close the > connection (after draining possibly pending data), just as it would do > on a redirect to another domain" > > > >From what I remember of my last reading of draft-19, it was clearly stated > >that if a transfer-encoding other than chunked is present, then chunked > >MUST > >be present last so the transfer is always chunk-encoded, precisely for this > >issue. You can send safely reject messages which contain Transfer-Encoding > >without "chunked" as the last one (you'd better recheck the spec than take > >my word for it though). > > There is no mandate that chunked is *always* to be used with them > though. Only that when combined the best is last. Yes, I just found it : http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.1 If any transfer-coding is applied to a request payload body, the final transfer-coding applied MUST be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied MUST be "chunked" or the message MUST be terminated by closing the connection. > We have had to take that assumption on our own guess at good-practice in > Squid and decoded to always chunk 1.1 when content-length is missing. > Regardless of other encodings. I think this was recent additions from http-bis (which is a very important one). Regards, Willy
Received on Friday, 20 July 2012 07:08:40 UTC