Subject: RE: Content negotiation for request bodies

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 14 Mar 2008 00:50:16 +0100

On Sun, 2008-02-24 at 10:24 -0800, Brian Smith wrote:
> > 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.

I disagree.

Content-Encoding is an entity header.

PUT is defined as storing the enclosed entity, which includes any
entity-headers.

The loophole is that it's not specified how PUT affects the state of a
server, which by side-effect allows for servers to perform any
processing they like of the entity enclosed in PUT before storage. But
the fact that something is allowed by side-effect do not mean that thats
the intended behavior.

Regarding POST it's a more open question, but POST is an application
level protocol exchange, and it can be expected the two endpoints have
already negotiated the needed parameters by the same means the agent got
the URI to POST to. This is already done in HTML, and expected by other
applications making use of POST.

Regards
Henrik

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 13 Mar 2008 21:27:08 -0700

Henrik Nordstrom wrote:
> > There aren't any agreed-upon expectations for how 
> > compressed request bodies are processed; that is
> > the problem.
> 
> I disagree.
> 
> PUT is defined as storing the enclosed entity, which includes 
> any entity-headers.
> 
> The loophole is that it's not specified how PUT affects the 
> state of a server, which by side-effect allows for servers to 
> perform any processing they like of the entity enclosed in 
> PUT before storage. But the fact that something is allowed by 
> side-effect do not mean that thats the intended behavior.

That sounds sensible, but (a) it doesn't help in the case that the
server rejects requests with a Content-Encoding header, and (b) many
servers do not follow the requirement to store all the entity headers.
At best, servers store the entity headers that they understand. But, it
isn't sensible or safe for them to parrot headers they don't understand.
That is why I raised the "unknown and misplaced headers as entity
headers" issue.

- Brian