- From: Adrien W. de Croy <adrien@qbik.com>
- Date: Mon, 18 Mar 2013 08:59:02 +0000
- To: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
there are some interactions with caches. 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, and discard its own copy. I think really if we're to introduce this sort of allowed behaviour, we need to do a bit more work on the spec, if only to cover the other parts where IMS is covered etc. And set some rules. Adrien ------ Original Message ------ From: "Amos Jeffries" <squid3@treenet.co.nz> To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org> Sent: 18/03/2013 9:17:26 p.m. Subject: Re: WGLC p6 4.2.1 >On 18/03/2013 7:58 p.m., Poul-Henning Kamp wrote: >> In message <em2a931273-ea65-4c5c-83d3-2d9698e19de0@bombed>, "Adrien >>W. de Croy" writes: >> >>> 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. >> There are several uses I know of, where IMS is used by clients >> without having an older object, as a way to say "Is a recent version >> of this object available ?". >> >> One such usage is "Are there any severe weather warnings published >> in the last 24 hours ?" which avoids pulling the "no warnings" >> boilerplate most of the year. >> >> I will fully agree, that using only values originally received from >> the server is a lot more water-tight, and is to be strongly >>recommended >> (at the SHOULD level), but trying to outlaw other values is a waste >> of everybodys time, given that such a ban cannot be sensibly enforced >> by us. >> >> If the server for some reason insists on not receiving arbitrary >> timestamps in IMS, it can use E-tags, which by definition are >> impossible to synthesize anywhere else. > >+1 on what PHK said. > >A client with out-of-band information about the server state should not >be hindered by HTTP as to the conditionals it makes a request with. >As long as the server response is correct in relation to those >conditionals it cannot cause problematic side effects elsewhere than >the >client itself, since all intermediaries will be considering that >request+reply in isolation. > >Amos >
Received on Monday, 18 March 2013 08:59:30 UTC