Re: [Fwd: Re: PUT vs strong ETags]

On Dec 7, 2005, at 5:49 PM, Jim Whitehead wrote:

> I don't have a firm read on whether the Apache HTTPd behavior is  
> non-compliant. However, I strongly feel that its current behavior  
> is very bad for clients.
>
> What clients really need is for the ETag to not change unless the  
> content changes.

   Well, I'd argue that what they *really* need is for the ETag to  
change if the content changes.

   While I agree than changing the ETag for otherwise-same content is  
inconvenient and best avoided, unless it's happening a lot (it this  
case it happens at most once), I don't see that as tragic.

   Note that this situation only arises during the one-second span of  
time that a resource is modified.  That does mean that it's almost  
always going to yield the "temporary" ETag on a PUT request, but  
rarely on a GET.

   As long as httpd is using a filesystem timestamp to compute the  
ETag, this is going to be unavoidable.  An MD5 hash would be a great  
ETag, but it, and anything that involves opening the file, is far  
more expensive to compute.  I think the trade-off here is a  
reasonable one, given the data we have available.  The other option  
is to punt and not emit an ETag, since we arguably don't have  
accurate enough information.  But I think that would be worse.

   Anyway, whether it changes or not is unrelated to the issue I'm  
angling for, which is whether the use of a weak etag is wrong.

> So, if an ETag starts out weak, it should stay weak. If it starts  
> strong, it should stay strong. The weak->strong transition is a  
> problem. I don't think clients care particularly about weak vs  
> strong etags. In fact, if the server does some amount of background  
> processing on the content, but returns a semantically equivalent  
> representation then the server should be using weak etags  
> consistently, AFAIK. For example, if a CalDAV server receives an  
> event, bursts it out into its database, then reconstructs a  
> slightly different XML representation that is semantically  
> equivalent, it should only be using weak etags in this case to  
> represent the fact that there are minor tweaks to the  
> representation of the resource.

   OK, that's a vote for "the weak etag is wrong".

	-wsv

Received on Thursday, 8 December 2005 02:35:32 UTC