W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: WGLC #354 - ETags & conditional requests

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 22 Jun 2012 10:35:17 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Message-Id: <4DEBDF43-17B3-4EA7-A014-46932F037CCA@mnot.net>
To: Zhong Yu <zhong.j.yu@gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 00:35:57 GMT