Re: WGLC p6 4.2.1

"Adrien W. de Croy" <adrien@qbik.com> wrote:
 
> From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>

> >In message <em94119d23-43b0-4de4-a3e3-8c30e8a40bfc@bombed>, "Adrien W. 
> >de Croy" writes:
> >
> >>>>for instance a cache receiving a request with If-Modified-Since 
> >>>>later
> >>>>than its own Last-Modified, may presume the client has a later 
> >>>>copy,=20
> >>>>and
> >>>>discard its own copy.
> >>>
> >>>Uhm, so you're saying I can clean the entire cache with bogos IMS
> >>>requests ?
> >>
> >>that's not the point.
> >
> >It very much is: A cache would have to be stupid to make that
> >assumption, and we should not be protecting stupid mistakes with
> >the specification, we should make things work.
> it was just one example.  There are potentially limitless ones.
> 
> fundamentally, we're changing the semantics.
> 
> Do we even know what that may break?

Privoxy has supported modifying the If-Modified-Since and
Last-Modified dates for years to make using them as cookies
less convenient:
http://www.privoxy.org/user-manual/actions-file.html#HIDE-IF-MODIFIED-SINCE
http://www.privoxy.org/user-manual/actions-file.html#OVERWRITE-LAST-MODIFIED

As far as I know this didn't break anything except for the
user tracking (provided no additional tricks are used).

Modifying the If-Modified-Since date comes with the risk of ending up
with a stale copy, but if the modification range is small it's usually
not a problem.

> >No matter what you write in the specification, you will have IMS
> >headers with non-server-supplied timestamps, because it is possible
> >and there are legitimate use-cases.
> I agree it's possible, I'm not sure about the use-cases. at least not 
> the one you mentioned before.
> 
> Sending If-Modified-Since currently indicates you have a copy.  So we're 
> looking to break that too?

In my opinion it only indicates that you don't want a copy
if it isn't more recent than the given date.

RFC 2616 14.25 even allows sending an arbitrary date ...

> >We can discuss if the text expresses this optimally, but there is
> >no way the text can put this particular genie back in his bottle.  
> I think we will need to make further changes, to refer to these changes 
> elsewhere in the spec, e.g. where it's discussed that to make a 
> conditional request one adds If-Modified-Since using the content of a 
> previous Last-Modified response header.

My interpretation of "4.2. Validation Model" is that it's only
relevant for certain conditional requests and thus doesn't prohibit
sending other dates for other conditional requests.

Fabian