W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: PROPOSAL: Weak Validator definition [i101]

From: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
Date: Tue, 18 Mar 2008 12:22:42 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Lisa Dusseault <lisa@osafoundation.org>, Werner Baumann <werner.baumann@onlinehome.de>, ietf-http-wg@w3.org
Message-ID: <20080318112242.GF2405@polar.elf12.net>

On Tue, Mar 18, 2008 at 11:23:22AM +1100, Mark Nottingham wrote:
> 
> Are you seeing any clients who are using the weak etags in a way  
> that's different from how they'd behave if you sent a strong etag?

Only for full-body conditional GETs the answer is "no".

I think the big questions is: Do we want to cache documents that just 
changed when we asked for them AND could have changed once again in that 
second?

Apaches weak etags would provoke that, which for me makes no sense. - 
The server obviously does not care if some client stays with old and 
possibly completely "wrong" data. This is what we have now and we could 
judge:

a) that's fine, the server sends weak etags whenever it likes
b) that's not fine, weak etags stand for "semantic equivalence"
   -it is still the servers task to rule something equivalent
   -but "semantic equivalence" is definitively content based, not 
    modification time based


I personally don't like careless server behaviour like a); a 
document that changes "so often" is in my view probably out of date. 
Servers should not generate an ETag in this situation if they have no 
better means.


Robert


> 
> 
> On 18/03/2008, at 10:47 AM, Robert Siemer wrote:
> 
> >
> >On Tue, Mar 18, 2008 at 09:44:07AM +1100, Mark Nottingham wrote:
> >>
> >>This crossed my mind as well... Weak ETags are in use today, but can
> >>we find a situation where they're actually improving things, and
> >>getting interoperability?
> >
> >What is so bad with my CGI example? If I change something in the  
> >script
> >that will make it's output different but has no semantic importance, I
> >use weak etags. - You could argument that it is not worth caching at
> >all, but please, get rid of "same second as now"-last-modified headers
> >first. And that way the whole weak validator story can go.
> >
> >(I don't see any interop issues with browsers on weak etag resources.)
> >
> >
> >>On 18/03/2008, at 8:57 AM, Lisa Dusseault wrote:
> >>
> >>>Strawman proposal "Die die die": get rid of weak Etags.  Do this by
> >>>making the W/ prefix simply part of the ETag.  Alternatively, do
> >>>this deprecating: recommend clients to ask again or not use etags
> >>>that begin with W/.
> >
> >
> >
> >
> >Robert
> >
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 
Received on Tuesday, 18 March 2008 11:21:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT