Re: Etag-on-write, draft -04

On Nov 29, 2006, at 3:45 PM, Lisa Dusseault wrote:


> On Nov 29, 2006, at 3:13 PM, Wilfredo Sánchez Vega wrote:
>
>>   What is the point of issuing an ETag on PUT that is not useful  
>> for any request that follows?  It's completely misleading because  
>> it implies that the client has something that should be cached,  
>> when it fact it already has a stale copy.  That's bogus.
>
> So what would be the client behavior if the PUT response contained  
> no ETag in the ETag header (and no last-modified header)?  Then the  
> client could not assume that the content had not been modified,  
> which would be correct behavior.  Later if the client does a HEAD,  
> PROPFIND or other, the server could provide the post-modification  
> ETag.
>
> This could be less bogus than the proposal for a "never-valid" ETag  
> that's not useful for any request that follows.
>
> What I'd like to come up with is proposals that allow a new client  
> to work well with existing servers, and a new server to work well  
> with existing clients.  Sometimes there are cheap things you can do  
> to make those cases work even if there have been bad assumptions in  
> the past.

   Sure.  I don't think your solutions are cheap long-term, is all.   
They are convenient for today's clients, but I'd rather do the right  
thing for future clients.  There aren't that many clients today, and I  
don't think Julian's spec makes life practically hard for existing  
clients.

   In the case where a server does not modify content, things continue  
to work as "well" as they work today.  In the case where the server  
does modify content, existing clients are already broken.  I don't  
believe that today's clients really care, because they aren't designed  
to work with such servers in any case.

   I therefore don't think that catering to today's broken clients  
should prevent us from pursuing the best option for tomorrow's  
(hopefully) less-broken clients.

> Right now we have three interesting things to flag (no change,  
> harmless change, big change) and our existing tools only allow us to  
> flag two of those things.

   False.  Existing tools don't allow us to flag *any* of these things  
in the reply to a PUT request.  Some clients are assuming "no change"  
without any real justification, other than the fact that most servers  
out there seem to not change the data.  The only way to really know  
this today is to follow a PUT with a GET, in which case, you arguably  
can identify all three cases.

>   The major question is whether "harmless modifications" should be  
> flagged in such a way so that:
> 	1. Deployed clients can't distinguish a harmless modification from  
> the case where no modification occurred; only upgraded clients can  
> tell the difference by using a new header
> 	or 2.  Deployed clients can't distinguish between a harmless  
> modification and a major modification done perhaps by another  
> client; only upgraded clients can tell the difference by using a new  
> header
>
> I believe the proposal in the draft describes case 1, whereas case 2  
> would be safer.
>
> In any case, major server modifications (non-harmless) should never  
> treated in such a way that they appear as if no change occurred to  
> deployed-base clients.  Do we generally agree on that?

   No, because one of the existing client scenarios is the file system  
clients, and those clients want harmless modifications to be refreshed  
as much as they want major ones.  When I open a document on my Mac, I  
expect to see the document as it exists on the file server.  If the  
file server made "harmless" changes, I expect them to be there.

   For those clients, all servers that modify content appear broken.   
The only way for those clients to reliably work with such a server is  
not to trust the ETag on PUT at all.  If they don't do that today, the  
workarounds you are suggesting don't reliably fix them.

   In any case, I am unaware of any cases where someone mounts a  
content-modifying DAV service as a file system and expects it to  
work.  So the use case you want us to design around seems theoretical.

	-wsv