Subject: If-Match header question

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 18 Aug 2005 09:14:38 -0700

RFC 2068 12.25 says that for the If-Match header, one should  
respond with 412 (precondition failed) if the header doesn't match up  
with the ETag of the resource.  OK, cool.

   However, it goes on to say that if, without the If-Match header,  
the request would have resulted in a 200-series response, that the  
header must be ignored.

   This is a little tricky.  For example, if a PUT request would  
error out due to a filesystem permissions issue, the only way for me  
to find that out is to attempt to write the file.  If that works, I'd  
then have to back out the change and respond with a 412.  That seems  
like a lot of extra work there.

   There are many less expensive to detect error cases, such as  
forbidden do the auth config, etc., which presumably is what this  
line is chasing after, but even these cases seems like a lot of  
code.  Without that requirement, I can do an If-Modified test on all  
resources for all requests right away and respond with a 412 if  
appropriate.  This language seems to imply that I instead have to put  
logic into each method which attempts the request and responds with  
412 instead of a success code after potentially backing out the  
operation.

   Am I reading that wrong?

     -wsv

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Aug 2005 18:11:48 +0200

Wilfredo Sánchez Vega wrote:
>   RFC 2068 12.25 says that for the If-Match header, one should  respond 
> with 412 (precondition failed) if the header doesn't match up  with the 
> ETag of the resource.  OK, cool.

Actually, what's relevant is RFC2616 which obsoletes RFC2068.

>   However, it goes on to say that if, without the If-Match header,  the 
> request would have resulted in a 200-series response, that the  header 
> must be ignored.

..other than a 2xx or a 412 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.24.p.6>):

"If the request would, without the If-Match header field, result in 
anything other than a 2xx or 412 status, then the If-Match header MUST 
be ignored."

So this has indeed been fixed.

 > ...

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 23 Aug 2005 10:01:30 -0700

On Aug 23, 2005, at 9:11 AM, Julian Reschke wrote:

>> respond with 412 (precondition failed) if the header doesn't match  
>> up  with the ETag of the resource.  OK, cool.
>

   Yes.

>>   However, it goes on to say that if, without the If-Match  
>> header,  the request would have resulted in a 200-series response,  
>> that the  header must be ignored.
>
> ..other than a 2xx or a 412 (<http://greenbytes.de/tech/webdav/ 
> rfc2616.html#rfc.section.14.24.p.6>):
>
> anything other than a 2xx or 412 status, then the If-Match header  
> MUST be ignored."
>

   No, my concern isn't about 412.  My concern is about any other  
possible error, such as permission errors, or other errors specific  
to the operation being requested.  In the case of PUT, if the PUT  
would fail due to a filesystem error which would result in an error  
response (for example, disk is full and a 507 is appropriate), the  
spec as written requires that I ignore the If-Match header.

   The problem is that in some cases, the only way to know what the  
error condition would be is to actually try the operation.  Doing so  
could be expensive, and could require restoring everything back to  
its original state when you find out that there is, in fact, no  
error, which is presumably the most common case.

     -wsv

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Aug 2005 19:09:42 +0200

>   No, my concern isn't about 412.  My concern is about any other  

I see. I thought that including the 412 into the sentence would resolve 
the issue, but it doesn't :-)

> possible error, such as permission errors, or other errors specific  to 
> the operation being requested.  In the case of PUT, if the PUT  would 
> fail due to a filesystem error which would result in an error  response 
> (for example, disk is full and a 507 is appropriate), the  spec as 
> written requires that I ignore the If-Match header.

Yes.

> could be expensive, and could require restoring everything back to  its 
> original state when you find out that there is, in fact, no  error, 
> which is presumably the most common case.

I absolutely agree, and I don't think anybody actually implements this 
per spec. You probably should report this to the HTTP WG 
(<[email-masked]>).

Best regards, Julian