RE: Content negotiation for request bodies

Henrik Nordström wrote:
> Brian Smith wrote:
> > 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."
> 
> 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. 

Besides Content-Encoding, Content-Type is important, especially with
charset parameters. 

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

I disagree. It just means "I'm sending you something and it is
compressed." Nothing more or less.

> The server obviosly MAY inflate the 
> entity or perform whatever processing on it it likes

Right.

> but that's not the primary expectations of HTTP for PUT.

There aren't any agreed-upon expectations for how compressed request
bodies are processed; that is the problem.

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

A TE in a response to OPTIONS implies that the listed encodings are
valid for any method. The "Expect: 100-continue" can handle this on a
per-method (actually per-request) basis. I think both mechanisms are
useful. If you allow TE in OPTIONS responses, you might as well allow
Accept-* for OPTIONS too.

- Brian

Received on Sunday, 24 February 2008 18:24:19 UTC