Re: NEW ISSUE: Content-* headers vs PUT

James Snell writes:
    
    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.
    
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

Received on Friday, 27 July 2007 20:09:54 UTC