Content negotiation for request bodies

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."

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

Received on Thursday, 14 February 2008 22:58:11 UTC