Subject: proposed change for Issue 103 (content-*)

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Nov 2008 15:20:05 +0100

Hi,

I propose to close issue 103 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/103>) with the 
following change:

OLD:

   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.

NEW:

   NOT ignore any Content-* headers (e.g. headers starting with the
   prefix 'Content-') that it does not understand or implement and MUST
   return a 501 (Not Implemented) response in such cases.

See also: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/103/>.

BR, Julian

---

From: Dan Winship <[email-masked]>
Date: Tue, 04 Nov 2008 09:45:40 -0500

>   return a 501 (Not Implemented) response in such cases.

s/e.g./i.e./. (Or just get rid of it.) Otherwise it suggests that there
are "Content-* headers" that don't start with "Content-".

-- Dan

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Nov 2008 16:00:19 +0100

> are "Content-* headers" that don't start with "Content-".

Good catch. So

OLD:

NEW:

    NOT ignore any Content-* headers (headers starting with the prefix
    'Content-') that it does not understand or implement and MUST return
    a 501 (Not Implemented) response in such cases.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 4 Nov 2008 09:59:25 -0600

Julian Reschke wrote:
>     'Content-') that it does not understand or implement and MUST

Given that this requirement is almost universally ignored, is practically
useless, is ill-defined, and is inconsistent between PUT and other PUT-like
methods, the whole statement should just be removed.

For example, let's say the client includes a Content-MD5 in a PUT request.
What is the server's responsibility here? As long as it puts Content-MD5 on
a "safe-to-ignore" list then it is conformant. But, the behavior is exactly
the same as if it wasn't maintaining a "safe-to-ignore" list in the first
place.

Why should the server be free to ignore all Content-* headers in every other
method besides PUT? Why should the client be free to ignore all the
Content-* headers? If they are a "must understand" requirement they must be
important for the client too.

In many applications (e.g. AtomPub) POST and PUT are very, very similar and
requirements like this should apply to both POST and PUT. For other
applications, this requirement might be inappropriate (especially for POST).

Since it is an application-specific requirement, and since the vast majority
of implementations ignore this requirement, there's no reason to keep it in
the protocol.
 
Regards,
Brian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Nov 2008 17:16:43 +0100

> methods, the whole statement should just be removed.

Potentially, yes. We've got a separate ticket for that one: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/104>, where Roy wrote:

> If we change the spec to say that all unrecognized header fields should simply be ignored (forwarded downstream but never saved), then a lot of these strange handling requirements can be removed. My guess is that "must ignore" behavior is more consistent with current implementations than what is specified in 2616. 

But I do not believe we have consensus on that one yet, so fixing issue 
103 still seems to be useful.

> ...

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Nov 2008 11:15:18 +0100

>    a 501 (Not Implemented) response in such cases.

Applied patch and closed issue with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/333>.

BR, Julian