- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 29 Feb 2008 10:22:31 +1100
- To: Brian Smith <brian@briansmith.org>
- Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
That's a pretty big change, considering the previous text; > The recipient of the entity MUST NOT ignore any Content-* (e.g. > Content-Range) headers that it does not understand or implement and > MUST return a 501 (Not Implemented) response in such cases. Doing away with this would likely cause problems for existing implementations (and WebDAV?). For non-PUT methods, the default is already to ignore the headers you don't understand. Regurgitation for the case of POST is an application- specific thing, and I'm not sure what the spec can really say about that; it's more implementation advice than HTTP spec language. Other methods that may have "regurgitation" implications -- e.g., PATCH -- will have to craft their own language like POST's. So, I'm -1 on i102 (which is what this discussion is really about). On 29/02/2008, at 12:07 AM, Brian Smith wrote: > 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. -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 28 February 2008 23:23:02 UTC