- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 11 Nov 98 14:58:51 PST
- To: Ross Patterson <ROSSP@ss1.reston.vmd.sterling.com>
- Cc: http-wg@hplb.hpl.hp.com
- Message-Id: <9811112258.AA10530@acetes.pa.dec.com>
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