W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Content-* Semantics [i103]

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Feb 2008 16:15:21 +1100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <D57871E5-7895-41C4-8D71-A14678135A06@mnot.net>
To: Brian Smith <brian@briansmith.org>

That's an interesting way to state the problem; I hadn't thought about  
it in terms of mU, but of course that's what it is currently for PUT  
(and PUT only, at this point, although we have a companion issue for  

Certainly, if this pair of issues were resolved in the most general  
fashion, it would make Content-* look like HTTP's mU mechanism (at  
least for requests with a body), and knowing how some people out there  
think (e.g., the WS crowd), this could easily be abused.

I think, however, that the key here is knowing what 'understand'  
means. For PUT, it pretty much means "store it and regurgitate it",  
with the additional caveat that if the server does any additional  
processing, it had better know the implications of things like Content- 
Type and Content-Encoding.

OTOH, POST falls into that latter category completely; all it does is  
processing. Even then, I'm not sure what "understand" really means,  
since a POST processor may not care a sausage for what Content- 
Language or even Content-Type means, depending on what it plans to do  
with the request.

See also <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/79>.

My .02 is that Content-* pretty clearly means all headers that have a  
Content- prefix, not just those defined by RFC2616. However, it  
doesn't follow that the "understand" rule for PUT should be  
automatically copied to POST and other request methods with bodies;  
and, I have a suspicion we'll be rewriting that language as part of  
#79 anyway.

On 28/02/2008, at 1:05 PM, Brian Smith wrote:

> Mark Nottingham wrote:
>> Now <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/103>.
>> I very nearly made this an editorial issue, but I thought
>> that it would be good to get general agreement that Content-*
>> is *not* constrained to just those headers defined by
>> RFC2616. Anyone have a problem with that?
> 1. Anybody can create a new must-understand header by naming it
> "Content-<something>." Is this desirable?
> 2. We cannot create must-understand headers without using that naming
> scheme. It seems odd.
> 3. Are headers prefixed with Content-* always entity headers?
> - Brian

Mark Nottingham     http://www.mnot.net/
Received on Thursday, 28 February 2008 05:15:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC