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

RE: Content-* Semantics [i103]

From: Brian Smith <brian@briansmith.org>
Date: Thu, 28 Feb 2008 05:07:24 -0800
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <000b01c87a0a$dd2d6320$6401a8c0@T60>

Mark Nottingham wrote:
> 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.

I think the intent is that headers like Content-MD5 (recalculate MD5 if
you encode/decode using Content-Encoding) and Content-Disposition (check
for path problems) need special processing when you "regurgitate" them.
Also, it usually doesn't make sense for the server to accept a request
with Content-Language: ko and then return the same entity with
Content-Language: jp or vice versa. But, it might make sense for it to
just not include a Content-Language header, which is what a lot of
servers do.

The requirement is relevant to POST and any other method. Perhaps the
requirement should be written as "Clients and origin servers SHOULD
ignore headers they don't understand and SHOULD NOT send headers they
don't understand (do not 'regurgitate' anything)", and moved to some
place that describes how headers should be processed generally. This
requirement is definitely not specific to PUT, considering that it often
applies to POST (whenever it is used as "PUT at server-assigned
location"), and will probably apply to PATCH too. And, it applies to
clients as well as servers; a client shouldn't send a header it receives
from a server unless it understands that header.

> My .02 is that Content-* pretty clearly means all headers that have a
> Content- prefix, not just those defined by RFC2616. 

If you accept the above suggestion, then the special treatment of the
"Content-" prefix is no longer needed, so the "Content-*" issue will be

- Brian
Received on Thursday, 28 February 2008 13:07:40 UTC

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