Subject: On the use of weak ETags for authoring

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jul 2009 12:19:07 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Jul 2009 17:55:13 +0200

Henrik Nordstrom wrote:
> Just to be clear, the text only clarifies what RFC2616 already said.
> There is no actual change in the comparision function, just different
> wording.
> 
> Regarding wording I think the explicit mention of weakness should be
> added back to the weak comparison function as it adds clarity to those
> who don't quite remember that opaque-tag do not include the weakness
> indicator (this is defined many sections away).
> 
> From:
> 
>       * The weak comparison function: in order to be considered equal,
> To:
>       * The weak comparison function: in order to be considered equal,
>         both opaque-tags MUST be identical character-by-character, but
>         either or both of them MAY be tagged as "weak" without affecting
>         the result.

Yes, I agree we went a bit too far when rephrasing it; I've committed 
your proposed change as 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/610>.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Jul 2009 13:28:03 +0200

Julian Reschke wrote:
> ...

Hi,

Henrik just pointed out that P4 still required strong matching in the 
definition of "If-Match", which we just fixed with:

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/656>

BR, Julian