Re: Content negotiation for request bodies

tor 2008-02-14 klockan 14:58 -0800 skrev Brian Smith:
> 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."

Sounds like a reasonable approach to me, and is infact already in the
specifications in "Use of the 100 (Continue) Status". See also below.

Adding full Accept-* negotiation would be a bit overkill imho. It's a
pretty rare case, and in most cases the application protocol defines
what entity types is acceptable. Content-Encoding is part of the
HTTP/MIME entity type specification, not a "dynamic compression". I.e. a
PUT with Content-Encoding: deflate means store a deflated entity on the
server, not that the server should inflate the entity and store the
"original". The server obviosly MAY inflate the entity or perform
whatever processing on it it likes, but that's not the primary
expectations of HTTP for PUT.

A more valid question for HTTP specification is server ability to
advertise transfer-encoding support beyond chunked. The TE header is
today declared as a request header, but should probably be generalized
to be included in OPTIONS responses and 501 responses.

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

Correct.

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

Agreed.

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

If really needed I think a better approach would be to push a little
more for 100 Continue and the benefits of it in general. Pretty much the
exact same problem of backing off nicely applies to any "request not
satisfiable" condition when trying to send a request entity.

   - Malformed requests
   - Unacceptable request entityt types
   - Unacceptable transfer encoding
   - Authentication required
   - Not authorized
   - Server error
   - Redirection
   - etc etc..

Regards
Henrik