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

tis 2007-05-29 klockan 21:01 +0100 skrev Jamie Lokier:

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

Because the validator isn't strong and as such do not guarantee the
entity will be binary equivalent, only semantically equivalent.

Range merging is only safe if there is a strong indication from the
server that the parts come from the same entity. For this reason
If-Range only supports strong ETag:s as it's only when the server has
given the response a strong ETag one can assume binary equivalence.

If-None-Match is the only conditional allowing weak ETag. This is used
for cache validations and Vary probing.

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

Why? A strong one can always be used.

The only reasons to specify a weak ETag is if you can't or don't want to
fulfill the uniqueness requirements of a strong one.

can't: When binary equivalence can not be guaranteed between two
requests. For example dynamic compression with a embedded timestamp, or
when there is other "random" elements in each response.

don't want to: When each response is unique, but it's at the same time
not very important that the user always gets the most current. For
example a hit counter.

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

???

Can you give some examples please. I just don't see what you are talking
about here..

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

Already the case, if Apache follows the RFC.. The initial response will
have a weak ETag, which is then used in If-None-Match and should compare
true even after it has been upgraded to a strong one.

But please note that the Apache use of weak etags here is a bit flawed.
It's not really a good application of weak etags. But it's better than
not sending an ETag at all..

Regards
Henrik