On the use of weak ETags for authoring

[Julian Reschke]

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

[Julian Reschke]

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,
>         both opaque-tags MUST be identical character-by-character.
>
> 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

[Julian Reschke]

Julian Reschke wrote:

> 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,
>>         both opaque-tags MUST be identical character-by-character.
>>
>> 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>.
> ...

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