- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 27 Jun 2012 12:03:51 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
Haven't heard any objection, so I've assigned for incorporation in -20. On 22/06/2012, at 9:45 PM, John Sullivan wrote: > Mark Nottingham wrote: >> Of course, thanks; I always forget about the Range cases. >> >> How about: >> >> """ >> If any of the entity-tags listed in the If-Match field value match (as per Section 2.3.2) the entity-tag of the selected representation for the target resource, or if "*" is given and any current representation exists for the target resource, then the server may perform the request method as if the If-Match header field was not present. >> >> Origin servers must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, they must respond with the 412 (Precondition Failed) status code. >> >> Proxy servers using a cached response as the selected representation must not perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, they must forward the request towards the origin server. >> """ > > That sounds good to me - just a minor question about the wording: > > If any of the entity-tags listed in the If-Match field value match > (as per Section 2.3.2) the entity-tag of the selected representation > for the target resource > > That makes it sound like, in cases where the server has multiple > representations available, it will first choose one, *then* compare > with If-Match. (So if several equivalent versions are available and > If-Match contains one ETag, and the server chooses the "wrong" one > in step 1, it will always fail to match in step 2.) I just wondered > whether the opposite way is specifically excluded: search the available > versions for one matching an ETag present in If-Match, which will always > succeed if a matching representation is present. > > >> On 22/06/2012, at 1:43 AM, 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. >>> >>> 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/ >>>> >>>> >>>> >>>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> > > > John > -- > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 27 June 2012 02:04:20 UTC