W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: NEW ISSUE: example for matching functions, was: Weak and strong ETags

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 29 May 2007 19:50:53 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
Message-Id: <1180461053.6505.201.camel@henriknordstrom.net>
tis 2007-05-29 klockan 15:22 +0100 skrev Jamie Lokier:

> On this topic, if there are some clients (or proxy caches) who require
> byte-exact revalidations - i.e. strong comparison - and some clients
> who are fine with semantically equivalent revalidations - i.e. weak
> comparison - is that currently possible?

I expect most to not consider W/"1" and "1" as equal. Also consider it a
corner case which generally do not make any difference for any practical
operation of the protocol. The weak comparison function is only allowed
in simple cache validations.

I also expect many servers and proxies to not care very much about
weak/strong, just following the instructions by the client.

The most common example of where the same ETag exists in both strong and
weak is Apache, which uses weak ETags for objects modified very recently
(Last-Modified == Date), and upgrades the ETag to a strong one with the
same value when a bit of time has passed.

> Is that done by the server sending a weak Etag in a response, and
> giving clients the option to send a weak or strong version of that
> Etag in If-None-Match later?

Clients can not upgrade an weak ETag to a strong. Only the server can do
that. Doesn't make sense for a client to do this.

> If so, do deployed clients actually do that?  I.e. those requiring a
> strong comparison, do they strip away the W/ if it was present in an
> earlier response's Etag?

Any one requiring strong compare must consider any comparison where
either side is weak as false or invalid depending on the context (i.e.
servers seeing If-Range using and weak etag should consider the request

Clients constructing conditionals which need to be strong MUST only do
so using strong validators. If the client do not have a strong validator
and require one then it MUST NOT create the conditional.


Received on Tuesday, 29 May 2007 17:51:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC