Subject: NEW ISSUE: Content-* headers vs PUT

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jul 2007 19:35:36 +0200

Hi,

the description of PUT states 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6.p.1>):

"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."

It's not clear to me what Content-* headers are? All headers starting 
with the character sequence "Content-"? Just those defined in RFC2616?

Furthermore, that language sounds as if a server that ignores 
Content-Language (as opposed to storing it with the entity) MUST reject 
PUT requests that come with a Content-Language header. Is this really 
intended? Does anybody implement that?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 25 Jul 2007 19:53:36 +0200

>intended? Does anybody implement that?

I do not think it sounds like that, and don't think it's unclear which
headers are Content-* headers. If you understand or implement Content-
Language, you may "ignore" it as far as the requirement goes, and there
seem to be other valid forms of not ignoring a header. I would read this
as "reject content you don't understand"; if you don't do content-range
or content-encoding, that does indeed seem the only sensible course of
action. Less so for Content-Script-Type or Content-MD5.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jul 2007 20:00:55 +0200

> headers are Content-* headers. If you understand or implement Content-

Well, I think you're using a _very_ liberal interpretation. How can you 
say a server "implements" Content-Language, when it just drops the value?

> action. Less so for Content-Script-Type or Content-MD5.

It seems to me that this requirement currently is ignored in practice 
(will have to write test cases). This is a problem, either with the spec 
text, or with the implementations.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 25 Jul 2007 20:06:15 +0200

>say a server "implements" Content-Language, when it just drops the value?

I don't need to, as it is sufficient to "understand" the header...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jul 2007 20:13:40 +0200

> I don't need to, as it is sufficient to "understand" the header...

Good point.

So let's try to clarify:

(1) Any header starting with "Content-" not understood by the server 
needs to cause a 501.

(2) For the Content-* headers defined in RFC2616, this means:

Content-Encoding: store it with the entity, or drop it
Content-Language: store it with the entity, or drop it
Content-Length: must be checked (that's part of the message transmission 
semantics)
Content-Location: store it with the entity, or drop it
Content-MD5: check the hash code?
Content-Range: implement or reject
Content-Type: store it with the entity, or drop it

?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 25 Jul 2007 16:10:16 -0700

On Jul 25, 2007, at 10:35 AM, Julian Reschke wrote:
> the description of PUT states (<http://greenbytes.de/tech/webdav/ 
> rfc2616.html#rfc.section.9.6.p.1>):
>
> Content-Range) headers that it does not understand or implement and  
> MUST return a 501 (Not Implemented) response in such cases."
>
> It's not clear to me what Content-* headers are? All headers  
> starting with the character sequence "Content-"? Just those defined  
> in RFC2616?

Any header field name that begins with Content- (as reserved by MIME).

> Content-Language (as opposed to storing it with the entity) MUST  
> reject PUT requests that come with a Content-Language header. Is  
> this really intended? Does anybody implement that?

No.  The only reason it is in the spec, IIRC, is because some folks
wanted to squeeze Content-Range on PUT into the spec in spite of the
fact that it was known to fail interoperability on all deployed
servers.  Thus, an incompatible requirement was added to HTTP, over
the objections of the real vendors, in order to promote a feature that
did not yet exist.  It didn't work then, still doesn't work, and should
be removed from the spec.

PATCH is a better solution.  In PATCH, all of the Content- headers
refer to the patch entity. Any metadata that needs to be changed as
part of the PATCH can be changed through the use of a patch format
that contains metadata-deltas.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jul 2007 12:34:34 +0200

Julian Reschke wrote:
> ...

OK, tested with Apache/moddav (2.2.4), IIS (5), Xythos WFS and SAP KM, 
using Content-Range, Content-MD5, Content-Foobar.

Only one of the servers (Xythos) rejects all requests it should. IIS and 
SAP KM reject PUT/Content-Range, but not others. Apache/moddav 2.2.4 
accepts all of them and ignores them (opened issue: 
<https://issues.apache.org/bugzilla/show_bug.cgi?id=42978>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jul 2007 12:37:34 +0200

Roy T. Fielding wrote:
>> reject PUT requests that come with a Content-Language header. Is this 
>> really intended? Does anybody implement that?
> 

So I understand your recommendation would be to completely drop the 
requirement, dropping the last sentence from Section 9.6, p1 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6.p.1>):

?

> that contains metadata-deltas.

Agreed.

That also means that the same sentence should be removed from the PATCH 
spec, then.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Jul 2007 11:07:12 -0700

Julian: for the PATCH doc, how's this:

If a PATCH request contains any entity-headers the server does not
understand, the server MUST return a 501 (Not Implemented) response. A
server that understands a particular entity-header can choose to ignore
it; however, doing so can produce results that are unexpected or
unintended by the client. All entity-headers contained in the request
apply only to the contained patch document and MUST NOT be applied to
the resource being modified.

- James

Julian Reschke wrote:
> 
> Bjoern Hoehrmann wrote:
>> * Julian Reschke wrote:
>>> Well, I think you're using a _very_ liberal interpretation. How can
>>> you say a server "implements" Content-Language, when it just drops
>>> the value?
>>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Jul 2007 20:23:35 +0200

> understand, the server MUST return a 501 (Not Implemented) response. A

Hm. That makes PATCH "must-understand", contrary to most other HTTP verbs.

Why do we care?

> the resource being modified.

The last sentence sounds good, but I think everything else isn't needed.

Is there a particular header you have in mind that -- when ignored by 
the server -- would cause trouble?

Best regards, Julian

---

From: Jeffrey Mogul <[email-masked]>
Date: Fri, 27 Jul 2007 13:09:41 -0700

James Snell writes:

    If a PATCH request contains any entity-headers the server does not
    understand, the server MUST return a 501 (Not Implemented)
    response. A server that understands a particular entity-header can
    choose to ignore it; however, doing so can produce results that
    are unexpected or unintended by the client. All entity-headers
    contained in the request apply only to the contained patch
    document and MUST NOT be applied to the resource being modified.
    
This makes me nervous, for several reasons.

(1) It directly contracts a requirement in RFC 2616, in
section 7.1 (Entity Header Fields):

   The extension-header mechanism allows additional entity-header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient. Unrecognized header
   fields SHOULD be ignored by the recipient and MUST be forwarded by
   transparent proxies.

I suppose it is plausible that the PATCH doc could override this
"SHOULD" for the specific case of PATCH requests, but that seems
like it could prevent future extensibility.  At any rate, I think
if you are going to override this requirement, you should state
that explicitly -- otherwise, I can see implementors missing this
and perhaps mis-implementing it.

(2) My other concern is whether the verb "understands" is going to be
clear enough to implementors.

For example, if the request contains a request header defined
by RFC 2616 but not implemented by the server (for example,
Max-Forwards, which is normally implemented only by proxies),
it seems pretty clear that the PATCH server should not ignore
the request.  But I wonder if it's clear enough; careless 
server implementors could end up with implementations that do
not interoperate with clients or proxies that start inserting
request headers that aren't currently in widespread use (but
are legal RFC 2616 headers).

------

A modest proposal: we worried about something like this when we were
defining how caches should deal with request headers that they
didn't understand, and came up with the Vary header mechanism.
If correctly implemented, it's a simple way to remove ambiguity;
it says that the cache entry for this response depends on those
request headers, not just the request-URI.

Perhaps an analoguous approach would be a reliable way to
avoid ambiguities around headers in PATCH requests.  For example,
a new request-header (mandatory-to-implement for PATCH servers,
optional otherwise?) that says that this PATCH request depends
on the server "understanding" a set of entity-headers in the
request.

Something like:

	  Depends-on: content-encoding, content-type

If the server doesn't implement all of the headers listed
in the Depends-on header for a PATCH request, it MUST return
501 (Not Implemented).

-Jeff