- From: John Sullivan <jsullivan@velocix.com>
- Date: Thu, 21 Jun 2012 16:51:03 +0100
- To: Zhong Yu <zhong.j.yu@gmail.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Zhong Yu wrote: > A valid use case for GET + If-Match may be a range request. > > If the intermediary has a cached representation with matching tag, > which it has reason to believe would be the "selected representation" > from the original server, the intermediary may safely do the shortcut. > Otherwise the request has to be forwarded to the original server. Yes. It was only the conditional failure case that I was worried about, where the usefulness of this header is severely compromised by an intermediate generating 412s. > Zhong Yu > > On Wed, Jun 20, 2012 at 10:47 PM, Mark Nottingham <mnot@mnot.net> wrote: >> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/354>; related text is at <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#header.if-match> >> >> Usually, this isn't a problem, because If-Match is only used with methods that to be written through to the origin server. E.g., when you PUT or POST something. >> >> However, we shouldn't count on that. >> >> One way to address this would be to target the requirements at "origin server" rather than "server"; i.e. to say that we don't expect intermediaries to process If-Match. >> >> Thoughts? >> >> >> On 24/04/2012, at 3:47 AM, Ben Niven-Jenkins wrote: >> >>> Hi, >>> >>> Apologies that this mail misses the WG LC deadline, in Velocix we're reviewing all the HTTPBIS documents but we're a little behind, hence the late comments, sorry. (we're still reviewing so might have more comments as we work through the documents) >>> >>> On page 14 of P4 it states: >>> >>> If none of the entity-tags match, or if "*" is given and no current >>> representation exists, the server MUST NOT perform the requested >>> method. Instead, the server MUST respond with the 412 (Precondition >>> Failed) status code. >>> >>> This appears to apply to intermediates, but If-Match has a problem >>> here that If-Unmodified-Since does not. If a proxy has a cached >>> entity which has a newer Last-Modified timestamp it *knows* that >>> the conditional has failed and can generate the required >>> 412 Precondition Failed response itself. Otherwise it can satisfy >>> the request from cache. Or relay if there is no current cached >>> version. >>> >>> But because multiple responses with different ETags may exist then a cache receiving If-Match with one etag, when it has a different etag cached, can not know for sure that the request etag does not exist. If it were to respond with a 412 status it would effectively be preventing the use of that conditional. >>> >>> It would appear that the only two options available to an intermediate are to satisfy the request in the case of a known match, and relay upstream in all other cases (which would be in conflict with the spec as quoted above). >>> >>> Thanks >>> Ben >>> >>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> > > John --
Received on Thursday, 21 June 2012 15:51:38 UTC