- From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- Date: Tue, 23 Aug 2005 10:01:30 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Webdav WG <w3c-dist-auth@w3c.org>
- Message-Id: <8FAD64B5-6962-4717-AD82-2A40BCFFE0E6@wsanchez.net>
On Aug 23, 2005, at 9:11 AM, Julian Reschke wrote: > 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. 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>): > > "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. 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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 23 August 2005 17:01:51 UTC