Re: v11-03 COMMENT: 18.29 If-Unmodified-Since

    I-U-S raises the question, "Which headers must a compliant server
    support?" The wording in 18.29 If-Unmodified-Since requires specific
    behavior in response to this header that an otherwise compliant server
    would violate if it does not implement I-U-S.  (A server that does not
    implement I-U-S would return the resource with a 200 (OK) response.)
    
    Some questions, then:
    1) Was it the WG's intent to *require* I-U-S support?

The specific language that Dave refers to is:
    If the requested resource entity has been modified since the
    specified time, the server MUST NOT perform the requested
    operation, and MUST return a 412 (Precondition Failed) response
    with no Entity-Body.
Similar wording appears in section 18.26, If-Match.

The intent here is that if HTTP/1.1 clients want to use either of
these headers to prevent the misapplication of methods with
important side-effects, then it is only possible to use them
reliably if all HTTP/1.1 servers implement them.

For example, if one wants to prevent a PUT from changing a
resource that has already been changed by someone else, the
client could use If-Match (based on the entity tag returned
by a prior GET) or If-Unmodified-Since (based on the last-modified
value returned by a prior GET) to prevent the update if someone
else has changed the resource since the client's GET.

Even if we did insist that HTTP/1.1 servers implement these
headers, can a client be sure that the server it is talking
to is an HTTP/1.1 server?  Yes, in the case of If-Match, since
this requires an entity-tag and only HTTP/1.1 servers generate
entity tags.  Perhaps not, in the case of If-Unmodified-Since
(it depends on what else is present in the server's responses).

Note that we don't necessarily have to require intermediate
proxies to implement these headers, since we're using a
"write-through" (rather than "copy-back") caching model, and
the potential conflicts don't arise at caches.

I think it is not an unreasonable burden to require If-Unmodified-Since
support, but I'm less concerned with this than with making If-match
mandatory, since the latter is far more useful for this "safe PUT"
mechanism than I-U-S.

    2) Should the specification have a list of headers that a compliant
    client/server/proxy must support to be compliant?  (Possibly in an
    appendix, where it is not normative.)

Actually, if it's a question of what MUST be supported, then it
would be normative.  I think it might be a good idea for us
to have such a list, in the same way that RFC1122/RFC1123 had
similar lists.  At the very least, it would aid us in making sure
that we haven't screwed up on the MUST/SHOULD/MAY points.

-Jeff

Received on Tuesday, 14 May 1996 16:11:13 UTC