Re: Content negotiation for request bodies

Brian Smith wrote:
> One question I have frequently seen asked is "How do I know if the server supports compressed request bodies in POST and PUT requests?" Often the answer is "don't even try" or "try it, and if it fails, try without the compression." A better answer may be "Send the request, with the headers 'Content-Encoding: deflate' and 'Expect: 100-continue', and if you get a 100-continue response, send the compressed request body; otherwise send a new request without content-coding."
>

I don't see much difference between "try it, and if it fails..." and 
sending an Expects header.  Don't they amount to the same thing?  The 
problem with Expects, is it's only specified in HTTP 1.1, and every link 
in the chain must support it for it to work.  In the special case of 
Expects: 100-continue, this has grave problems with proxies that I've 
raised before, and a heuristic timeout waiting for a 100-continue which 
may never arrive causes further problems.

I guess the difference is in the amount of resource that may have 
already been sent before a failure comes back, and the failure code (501 
vs ...).  Balance that against the time you'd have to wait before giving 
up on getting a 100-continue back if the server were only HTTP/1.0, 
keeping in mind connecting to a proxy may be a lot quicker than the 
proxy connecting upstream.

A lot of work has gone into HTTP to try and cut down on round-trips - 
requests back to the server for whatever reason.  This has meant some 
compromises have been made especially when it comes to clients sending 
message bodies to servers. 

Simply because the first agent to send a message is the client (rather 
than the server), the server can know advertised client capabilities 
(i.e. Accept- headers) before choosing to send a resource that 
complies.  The client however cannot know what the server supports, 
because the server has not had an opportunity to advertise any 
capability.  There's no server welcome message.  So clients send message 
bodies blindly, whereas servers send message bodies with knowledge.

The result is that HTTP does not contemplate negotiating content 
transfers from clients to servers, only the other way around.  This is 
not such a problem for direct client-server comms, but when you 
introduce proxies in the chain, the problem is exascerbated.

Keeping in mind that there are many proxies potentially in a chain you 
don't know about.  Company intercepting proxies, ISP intercepting 
proxies, and a reverse proxy through to an origin server.  It's not 
uncommon to have about 3 proxies in a chain.

Regards

Adrien

> However, this is very dependent on the server correctly handling request Content-* headers, defined in Section 9.6 (PUT): "The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases."
>
> I would like to see the following changes made to the spec:
>
> 1. The requirement "The recipient of the entity MUST NOT ignore any Content-* headers" does not apply only to PUT, it also applies to POST any any other method where a request body may be sent. This requirement should be moved from Section 9.6 into another section that is not specific to PUT. This section should include Additionally, a note that says this is a common implementation error should be added to this section. 
>
> 2. A new worked example of the above (using "Expect: 100-continue" to send the server a compressed response if and only if the server responds with a "100 Continue") should be added to the section that describes the 100-continue mechanism. References to this new example should be added to the "Content Negotiation" section and to the "recipient...MUST NOT ignore any Content-* headers" section.
>
> Thoughts?
>
> - Brian
>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Thursday, 14 February 2008 23:42:17 UTC