W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Upload negotiation

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 09 Apr 2008 01:08:14 +1200
Message-ID: <47FB6E3E.8000500@qbik.com>
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 GMT

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