On the use of weak ETags for authoring

Hi,

it appears that there is some confusion about the usability of weak 
ETags for write operations, so it seems to me that it would be useful to 
summarize what the relevant specs say, and what changes we have made in 
HTTPbis so far...


1) Weak etags in non-GET requests

Historically, RFC2616 did not allow clients to perform conditional 
requests with weak etags for methods other than GET/HEAD (see 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.3.3>). 
That's a restriction that didn't make a lot of sense, as the server is 
in full control over which types of etags it generates, their semantics, 
and how it supports them in conditional requests. For instance, if the 
server does generate weak ETags, but does not want to support them in a 
PUT/If-Match, it will reject those requests with a 4xx status anyway.

So we relaxed this rule around a year ago (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/116>). The only 
restriction that stayed is related to byte-range requests (where you 
really really want a strong etag as validator).


2) Weak ETags in WebDAV

Related to this, WebDAV defines an additional conditional header called 
"If" (<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.10.4>), 
which never had the restriction mentioned above. So protocols that 
extend WebDAV already can use weak ETags in write requests.


3) Matching weak ETags

At least one popular HTTP server (in some configurations) assigns a weak 
ETag when a resource is created/updated, and only promotes it to a 
strong ETag later on (due to being based on a file system time stamp).

With <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/71>, also 
changed around a year ago, we have clarified that these two variants 
indeed match (weakly), and thus can be used in case where weak matches 
are sufficient.

This is a spec change that some have missed, so in doubt please review 
that you are ok with the current text in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-07.html#rfc.section.4.p.7>:

-- snip --
  The only function that HTTP/1.1 defines on validators is comparison.
    There are two validator comparison functions, depending on whether
    the comparison context allows the use of weak validators or not:

    o  The strong comparison function: in order to be considered equal,
       both opaque-tags MUST be identical character-by-character, and
       both MUST NOT be weak.

    o  The weak comparison function: in order to be considered equal,
       both opaque-tags MUST be identical character-by-character.

    The example below shows the results for a set of entity tag pairs,
    and both the weak and strong comparison function results:

    +--------+--------+-------------------+-----------------+
    | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
    +--------+--------+-------------------+-----------------+
    | W/"1"  | W/"1"  | no match          | match           |
    | W/"1"  | W/"2"  | no match          | no match        |
    | W/"1"  | "1"    | no match          | match           |
    | "1"    | "1"    | match             | match           |
    +--------+--------+-------------------+-----------------+
-- snip --

Best regards, Julian

Received on Wednesday, 15 July 2009 10:19:54 UTC