Re: Upload negotiation

or should the proxy always respond with the HTTP version number it 
received in a response?

I know for upstream the proxy should alway set the protocol version to 
it's own, but downstream?

Else there's no way a client can tell what the end server capabilities 
might be.


Adrien de Croy wrote:
>
>
> 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:10:25 UTC