Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Jamie Lokier schrieb:
> Yves Lafon wrote:
>>> Isn't this the problem scenario:
>>>
>>>   1. An existing deployed client (or cache, it doesn't matter) sends PUT.
>>>
>>>   2. The server sends 200 OK with Etag back in response.
>> Would it be OK for a server to return a 205 Reset Content with the Etag ?
>> That way the client would know that a refetch is in order.
> 
> No, because 205 Reset Content doesn't mean that.
> 
> Firstly, what's the point in sending the Etag in that case?  The
> client can't do anything useful with it.

Whether a refetch is in order isn't always clear. For instance, if you 
look at the keyword expansion example, a refetch may not be necessary, 
although the content was rewritten.

> Secondly, 205 Reset Content has a different meaning which won't be
> appropriate in many cases:
> 
>    the user agent SHOULD reset the document view which caused the
>    request to be sent. This response is primarily intended to allow
>    input for actions to take place via user input, followed by a
>    clearing of the form in which the input is given so that the user
>    can easily initiate another input action
> 
> Thirdly, 205 Reset Content does not mean "reset your cache entry to
> force a refetch", and existing clients and proxies won't do that.

Correct. Also, PUT says servers SHOULD return 200 or 204 on a successful 
PUT.

> To cause a refresh, "Cache-control: no-cache" in the PUT response
> _might_ work.  I'm not sure.
 >
>>>   3. Later, same client sends GET with If-None-Match and the Etag it
>>>      received in step 2.
>>>
>>>   4. The server sends 304 Not Modified, because the Etag matches
>>>      what it sent before.
>>>
>>>   5. The existing deployed client erroneously* uses the entity it
>>>      sent in step 1.  (If it's a proxy cache, it serves that entity
>>>      to its clients).
>>>
>>> * Erroneous only if the server is allowed to modify the entity it
>>> receives in PUT _and_ respond with an Etag which matches that modified
>>> entity.
>> What is the scope of the "modification" here? 13.3.3 says that the concept 
>> of a modification is up to the server.
> 
> 13.3.3 describes strong and weak validators, and explains that any
> change to the entity, including a semantically insignificant one,
> should change a strong Etag but doesn't have to change a weak Etag.
> 
> So the server is free to make modifications, but if it does then it
> shouldn't send a strong Etag corresponding to the modified entity in
> the PUT response.  It's ok to send a weak Etag corresponding to the

I'm not sure how you come to that conclusion. As pointed out in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.1.3>, 
"ETag" is a response header, and response headers per definition apply 
to the entity on the server, not the one in the request:

"The response-header fields allow the server to pass additional 
information about the response which cannot be placed in the 
Status-Line. These header fields give information about the server and 
about further access to the resource identified by the Request-URI." 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.6.2>).

> modified entity, provided the modification is semantically
> insignificant - and that _is_ up to the server.  It's also ok to send
> a strong Etag corresponding to the entity prior to modification.
> Useless (except in pathological cases), but ok.

We discussed this last year over here, and the consensus was that if an 
ETag is returned in PUT (or another write method such as PROPPATCH), it 
applies to what the server has, not what the client sent. I was 
surprised about that as well, and I really think a clarification of 
RFC2616 is required here. See also 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.3.p.7>.


Best regards, Julian


Best regards, Julian

Received on Thursday, 14 September 2006 10:27:52 UTC