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

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.

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.

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
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.

-- Jamie

Received on Thursday, 14 September 2006 10:02:54 UTC