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

Henrik Nordstrom wrote:
> > 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.

Well, clients can compare a weak Etag with a strong one and, according
to this thread, that sometimes returns true.  That means there's a
relationship between weak and strong Etags with the same value except
the W/.

So why not permit clients to convert a weak one to a strong one in
If-None-Match?  (For example, clients doing byte-range requests need a
strong validator every time.  It would be useful for that.)

> > 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
> invalid).
> 
> 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.

But what about the other way around?  Clients which require only weak
comparison, but the server must send a strong Etag so that _other_
clients, which require a strong comparison for the same resource, can
use conditionals?

It seems that it would be useful if a server could specify two Etag
for the same resource - a weak one, and a strong one.

That way, clients needing only semantic equivalence could use the weak
one, and clients needing byte equivalence could use the strong one.

Currently, a server can support conditionals for one type of client
but not the other.  That seems to be an unnecessary limitation.

Either permitted clients to convert a weak Etag to a strong one in
If-None-Match, or permitting multiple Etags in a response, would allow
conditionals by both types of clients.

(That would also improve cache hits with Apache's method - which uses
a weak Etag for resources with a recent time, then converts to a
strong Etag with the same value after the time has passed).

-- Jamie

Received on Tuesday, 29 May 2007 20:02:06 UTC