Re: Summary of ETag related issues in RFC2518bis

Dan Brotsky wrote:
> We're getting closer... :) 
> 
>> So let's look at what clients are interested in again:
>>
>> - they want to avoid fetching an ETag after PUT,
> 
> Yes.
> 
>> - in some cases, they want to be able to find out whether the 
>> server stored exactly what they sent,
> 
> No.  I claim no client wants to know this.  Ever.  If they really want
> to know that the content matches what they have, then they use a server
> that supports MD5 hashes and they rely on those.

It seems to me that many client implementors want this, because they may 
want to do Get/Range requests.

> If they are worried about network corruption then TCP/IP has things for
> that.
> 
>> - if they interleave PUT and PROPPATCH, they want their ETags 
>> to continue to work.
> 
> Yes.
> 
>> I believe all of these things can be accomplish by protocol 
>> extensions, and I'll be happy to spec them out. On the other 
>> hand, I don't think it would be a good idea to rush them into 
>> RFC2518bis, which was supposed to be finished around this 
>> time of year (if I may remember).
> 
> I believe all of these things that clients want are accomplished with
> what we have, as long as we have servers hand back strong etags on PUT.

1) Servers may not be able to return strong ETags upon PUT. Again, let's 
consider adding an indicator to PUT that let's the server know the 
client really needs a strong ETag, so that the server can optimize it's 
behavior for that case.

2) It seems to me that we can't rule out that servers touch the ETag 
upon PROPPATCH (for instance, because they are indeed updating metadata 
in the file content, such as with XMP). In which case telling the server 
to return the new ETag upon PUT seems to be a very good idea.

Best regards, Julian

Received on Wednesday, 21 December 2005 15:04:04 UTC