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

tis 2007-05-29 klockan 23:27 +0100 skrev Jamie Lokier:

> If it serves a strong Etag, the calendar client (for which weak
> comparison would be fine) will result in unnecessary network traffic
> sometimes - when a weak match would be fine, but a strong match fails.

Point taken.

But I suspect that in many of these cases Last-Modified is a sufficient
validator.

Extending HTTP to support more than one ETag is not possible. It's
pretty hardcoded at a single ETag per entity. Also this would make
handling of Vary even more complex than it is today..

> Either way, the limitation means redundant network traffic that can be
> avoided if either (a) the server can send two Etags, or (b) the client
> can convert a weak Etag to a strong one, when it requires a strong one
> or none at all.

I still don't see how converting the ETag to a strong one would work in
the context, no matter what the compare table looks like. The weak etag
simply do not carry the information you need as it's possibly shared by
multiple entities and if you just convert it to a strong ETag by
removing the weakness flag then you still don't know what it being
compared..


Related to this I still maintain that the restrictions on weak etags is
too strict, and should be allowed in If-Match for most operations if not
all. But that's a separate issue from the comparison function.

Regards
Henrik