- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 09 Apr 2008 01:08:14 +1200
- To: Henrik Nordstrom <hno@squid-cache.org>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Adrien de Croy wrote: >>> iii) praying that as a proxy we never get large chunked requests to >>> process for upstream HTTP/1.0 agents. >>> >> >> Proxies should respond with 411 in such case, making communication >> revert to "HTTP/1.0 compatible" with all the problems that have.. >> >> > > I guess so, or at least to retry without chunking. I guess the 411 > would come from the HTTP/1.0 server? How to tell that the server is > HTTP/1.0 if it doesn't recognise Transfer-Encoding, and just sees > chunk wrappers as part of the content anyway? Would it be purely lack > of Content-Length? Or would you have to rely on cached knowledge? > Just looked it up.. RFC1945 specifies that a server receiving a POST without Content-Length (or if it cannot determine the length - dunno how it could otherwise) SHOULD respond with a 400 (bad request). There's no code specified in HTTP 1.0 for length required, so I guess it comes down to a heuristic. If a proxy sends a chunked POST to a server, and that server responds with HTTP/1.0 and 400 (but not 401, 403 or 404) then the response the proxy should send to the client should be 411 Length required? Seems like a bit of an assumption, although the HTTP/1.0 is a bit of a giveaway, but it's still possible the request was bounced for some other reason, and will bounce again even if the client can and does submit with Content-Length. Cheers Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Tuesday, 8 April 2008 13:07:30 UTC