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

Re: WGLC p6 4.2.1

From: Fabian Keil <freebsd-listen@fabiankeil.de>
Date: Mon, 18 Mar 2013 14:17:27 +0100
To: ietf-http-wg@w3.org
Message-ID: <20130318141727.03ed374c@fabiankeil.de>
"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

Received on Monday, 18 March 2013 13:18:03 GMT

This archive was generated by hypermail 2.3.1 : Monday, 18 March 2013 13:18:06 GMT