- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Mon, 28 Apr 2008 21:27:51 +0200
- To: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
- Cc: Brian Smith <brian@briansmith.org>, "'Pablo Castro'" <Pablo.Castro@microsoft.com>, atom-protocol@imc.org, "'HTTP Working Group'" <ietf-http-wg@w3.org>
On mån, 2008-04-28 at 13:44 +0200, Robert Siemer wrote:
> That raises three issues:
>
> 1) It's not in RFC2616 (weak comparison for non-GET) and so it's not on
> RFC2616bis charta.
Not convinced. The current limitations on weak etags is just silly with
the exception of If-Range..
In my view it's a specification error that validators based on
Last-Modified is allowed in more places than weak etag based ones.
> 2) Weak ETags don't mean "semantically equivalent" anymore. They mean
> nothing now (see i101). As of today there is no replacement text
> proposed for i101, but weak ETags could get degraded to something way
> weaker than Last-Modified.
As specifiedin RFC2616 weak ETags is already less useful as cache
validator than Last-Modified, even if even the most trivial
implementations do generate a much stronger weak ETag cache validator
than Last-Modified.
> 3) the upgrade/downgrade questions will come up again:
> match_weak("xyz", W/"xyz")
>
> is 'true' or 'false'?
True. We have already beaten that discussion to death I think.
Specifications is very clear on this.
The error many seems to get trapped in is thinking that because of this
clients may upgrade the received weak etag as a strong one in order to
be able to acutally use the etag for anything useful, but this MUST NOT
be done and breaks the whole scheme in obvious ways.
Regards
Henrik
Received on Monday, 28 April 2008 19:28:48 UTC