- 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>
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 moot. - Brian
Received on Thursday, 28 February 2008 13:07:40 UTC