- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 18 Mar 2013 21:17:26 +1300
- To: ietf-http-wg@w3.org
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:17:56 UTC