- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 22 Jun 2012 10:35:17 +1000
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
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. """ 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/
Received on Friday, 22 June 2012 00:35:45 UTC