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

Julian Reschke wrote:
> 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 (headers starting with the prefix
>     'Content-') that it does not understand or implement and MUST
>     return a 501 (Not Implemented) response in such cases.

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

Received on Tuesday, 4 November 2008 16:00:35 UTC