WGLC p6 4.2.1

["Adrien W. de Croy" <[e-mail]>]

Hi all

I see there were some changes made to the 3rd bullet point in 4.2.1 
about selection of representations to update with a 304.

The new text hints that dates other than those received in a previous 
Last-Modified can be used to generate a conditional request with 
If-Modified-Since.

However, there are a number of side-effects with introducing this 
concept.

The previous iterations of the spec requires that If-Modified-Since may 
only contain the content of a previously received Last-Modified.  I 
don't know if it's wise to open this up.  We would need to consider what 
the side-effects of choosing any other date may be.

For instance if the sender (revalidating client) just chose the file 
date on the file in their store, it could bear no resemblance to any 
time on the server, and may appear to be a more recent copy than they 
actually have.  A server could then send a 304 back for content that was 
no longer valid.

So I think the date used in If-Modified-Since needs to have originally 
come from the server.  This only leaves Last-Modified, and Date.  Date 
could have been altered by intermediaries, so actually I feel it's 
unsafe to allow any other value than that contained in Last-Modified.

My original query about this point, which I suspect was a contributing 
factor to this change, was concerning receiving a 304 response to a 
request that related to revalidating a stored entry that had no 
validators.  My point at the time was that a 304 response to a 
non-conditional request is a server bug.  I would argue that 
constructing validators in a request where none were previously received 
is not valid (client can't invent ETag, and shouldn't invent 
Last-Modified), and so therefore my proposal was to strike this 
altogether, or prohibit it.

Regards

Adrien