Re: HTTP 1.1 issue 16: 14.26 If-None-Match

Ross Patterson writes:

    In section 14.26 "If-None-Match", the statements
    
       "If "*" is given and no current entity exists, then the
       server MAY perform the requested method as if the
       If-None-Match header field did not exist."

    and

       "The meaning of "If-None-Match: *" is that the method
       MUST NOT be performed if the representation selected by
       the origin server (or by a cache, possibly using the Vary
       mechanism, see section 14.44) exists, and SHOULD be
       performed if the representation does not exist."

    conflict on the topic of "If-None-Match: *". The former
    asserts that the server MAY perform the request, the latter
    that it SHOULD.  I think the MAY is correct.

Hmm.  I confess that I no longer remember all of the
discussion behind this, but I lean towards SHOULD.

Consider the request:

	PUT /foo.data HTTP/1.1
	Host: whatever.com
	If-None-Match: *
	Content-Length: 0

The basic intent is to prevent a race condition where the
origin server performs this request and overwrites an existing
resource when the client didn't realize it already exists.
But in the absence of that pre-existing resource, presumably
we want the effect to be the same as

	PUT /foo.data HTTP/1.1
	Host: whatever.com
	Content-Length: 0

Of course, I don't think we ever state whether a server
SHOULD or MAY perform any arbitrary (but valid) request
that it receives.  MUST would be too strong - there might
be resource constraints that the server needs to observe.
But I think it would be unfortunate if HTTP servers started
rejecting requests for essentially random reasons, and
not what the average user expects, and so "SHOULD" seems
like the more appropriate choice.

I'll avoid commenting on whether any existing implementations
do, in fact, reject requests for seemingly random reasons :-)

-Jeff

Received on Wednesday, 11 November 1998 15:03:15 UTC