Re: WGLC #354 - ETags & conditional requests

[John Sullivan <[e-mail]>]

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 <[e-mail]> 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
--