Re: Etag-on-write, draft -04

sön 2006-12-03 klockan 14:33 +0100 skrev Julian Reschke:

> Yes. So that solves the lost update problem (the refetch is safe not to 
> lose somebody else's update), but it still requires the client to refetch.

Or at least a HEAD roundtrip to verify the ETag, assuming the weak etag
it has been upgraded to a strong etag with the same value signaling that
the entity has been finalized. Or the specs changed to allow the weak
etag to be used as guard in future authoring.

Related note: If the server can not issue a strong ETag for the entity
even on a GET/HEAD then the lost update problem can not be fully solved
without changing the specs to allow for weak etags in PUT If-Match.

> The approach using the weak ETag has the problem requiring an additional 
> GET.

Yes, and only because the specs is afraid of weak etags of any other
condition which may be uncertain.

> I think in the end we should be able to come up with a solution where 
> these resources on these servers can be written to with no need of a 
> refetch. Optimally, that solution is compliant to RFC2616 (I would even 
> say it's required to be so, so that's why it's essential to clarify what 
> RFC2616 really is saying).

My view is that the best solution is to broaden the allowed use of weak
etags.

Many of these servers can not guarantee a octet equality on the objects
anyway. A slight change in software may change of the objects is
rendered back in the transmitted format, requiring all objects to have
new ETags assigned to them. CalDAV is one such example where the store
may be using a completely different format than seen on the wire.

> Ir would be good if at least a refetch GET could be avoided for every 
> but the last PUT.

Which allowing weak etags in PUT If-Match would do just fine.


> > Yes, and a weak etag is sufficient for solving the lost update problem.
> > If it wasn't for the stupid fact that a weak ETag can not be used in a
> > PUT/PUT If-Match sequence if following the spec.
> 
> So, can we resolve all of this by relaxing that requirement?

I think so.

A PUT returning a weak etag is sufficient for binding the PUT entity
together with the server entity when octet equality is not guaranteed.

The server then upgrading this to a strong ETag (with the same value) on
the provided resource allows for full utilization of the ETag on GET
request including If-Range.

And it's quite obvious that the returned weak etag does not guarantee
octet equality, so clients needing the exact representation know they
need to GET the finalized entity. And this works out even if the server
is still returning weak etags in the GET.

> That would indicate there's a real use case for have more information, 
> either by returning diff information as proposed by Roy, or by adding 
> more detailed information to Entity-Transform.

Neither works out very well I am afraid. The diff approach is the more
interesting I think, but this has to be left to the application. It's
not realistic for HTTP to specify a diff format which works for all
applications.



> "HTTP/1.1 does not define how a PUT method affects the state of an 
> origin server."

Yes, but what state?

You also have

 "The PUT method requests that the enclosed entity be stored under the
supplied Request-URI."

and

 "Unless otherwise specified for a particular entity-header, the
entity-headers in the PUT request SHOULD be applied to the resource
created or modified by the PUT."

when combined kind of rules out rewriting as in this set you have things
like Content-Length and Content-MD5.

> I do agree that upgrading weak ETags so they become usable for authoring 
> would be a potential solution to that problem. We would still need to 
> clarify RFC2616 with respect to returning ETags on PUT at all, and also 
> with requirements on strong ETags. And when making that change, we need 
> to take into account that we may break existing servers.

The specs does allow (and even clearly recommends in 201) ETags to be
returned, in all positive responses to PUT.

The weak area as I see it is specifying how servers not providing octet
equality should act to not confuse clients regarding the state of the
entity. It's quite obvious from this discussion that the RFC can be
understood in more than one way even after careful reading.

Regards
Henrik