Subject: If-match clarification

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jun 2007 11:59:05 -0400

Hi,
The description of If-match describes two possible situations, but those 
are not all that could occur:

1) If all etags in If-Match match, or If-Match * is used and the entity 
exists then normal processing occurs.

2) If any etags in If-Match do not match, or If-Match * is used and the 
entity does not exist, then 412 must be returned.

But what about the case of an etag provided in If-Match against a resource 
that no longer exists? Should the server return 404 or 412?

-- 
Cyrus Daboo

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 20 Jun 2007 22:44:28 +0200

> that no longer exists? Should the server return 404 or 412?

404 I would say, at least if it's a GET/HEAD.

Errors is not normally subject to If-* conditions. If-* conditions only
applies when the server actually could generate a successful response if
the condition was not there.

For PUT 412 is probably more appropriate there as it's the condition
which prevented the method from being executed, not the fact that the
resource no longer exists.

Regards
Henrik

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jun 2007 17:39:10 -0400

Hi Henrik,

--On June 20, 2007 10:44:28 PM +0200 Henrik Nordstrom 
<[email-masked]> wrote:

>> But what about the case of an etag provided in If-Match against a
>> resource  that no longer exists? Should the server return 404 or 412?
>

Actually I think being able to distinguish between "resource changed" vs 
"resource deleted" on PUT is useful. Consider that a client is likely using 
If-match in order to synchronize its changes with the server. So in the 
case of a "resource changed" the client would give the user three choices 
to fix: overwrite server copy with local copy, overwrite local copy with 
server copy, merge server and local copies. In the case of "resource 
deleted" there would only be two choices: save local copy to server, delete 
local copy. Being able to pick the appropriate course of action based on 
the response code (without the need to do another request to see if the 
resource exists) would be useful.

-- 
Cyrus Daboo

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 21 Jun 2007 09:05:18 +0200

ons 2007-06-20 klockan 17:39 -0400 skrev Cyrus Daboo:

> "resource deleted" on PUT is useful. 

And the application can easily and unambiguously learn the current
server state by issuing a HEAD request after the 412, and perhaps also
PROPFIND is using WebDAV.

Regards
Henrik

---

From: Jeffrey Mogul <[email-masked]>
Date: Thu, 21 Jun 2007 10:36:00 -0700

Actually, it says "if *none* of the etags match" ... this is
different from "if any do not match".  Probably this is what
you meant.

    But what about the case of an etag provided in If-Match against a
    resource that no longer exists? Should the server return 404 or
    412?
    
For this case, the actual language used is:

    ... if "*" is given and no current
    entity exists, the server MUST NOT perform the requested method, and
    MUST return a 412 (Precondition Failed) response.

I'm having a hard time understanding the difference between

  "no current entity exists" [for the resource identified by request-uri]

and

  the resource [identified by request-uri] no longer exists (does not exist)

Is there any practical difference between these two statements?

If not, then the meaning of the spec is pretty clear.  Whether it
is what we want is a different question; perhaps I could see returning
404 as being both more reasonable and easier to implement, but in
our current discussions, we're trying to avoid changing the spec.

(And it's not clear to me that GET and PUT should be specified
as generating different status codes in this case; that seems likely
to create complexity in the long run.)

-Jeff