Re: Why MD5 Headers are Imperative

>
>Eric J. Bowman schrieb:
>> "5.3
>>  
>>  Once a resource has been created and the URI of its Atom Entry Document 
>> (its 
>>  "Member URI") is known, that URI can be used to retrieve, update, and 
>> delete 
>>  the resource."
>> 
>> I'm saying this is a logical fallacy.  The Member URI may be used to update 
>> and delete the resource, but it will only ever retrieve a _representation_ 
>> of 
>> the resource.  Suggest:
>> 
>> "Once a resource has been created and the URI of its Atom Entry Document 
>> (its 
>> 'Member URI') is known, that URI may be used to update and delete the 
>> resource.  The Member URI may also be used to retrieve a readable 
>> representation of the resource or, using the Atom Protocol, a writable 
>> representation of the resource."
>
>Well, no matter what APP says, HTTP GET and PUT *always* transfer 
>representations. That's by design in HTTP, and APP can't change that. 
>That being said, I really don't understand how adding the sentence above 
>changes anything.
>

It doesn't change anything.  What it does is acknowledge that the readable 
and the writable representations of the resource are not, in Atom format, 
necessarily identical.

>> ...
>>> example for that? In particular, why isn't a string ETag sufficient, and 
>>> if it isn't, why doesn't that cause problems in WebDAV as well?
>>>
>> 
>> Because WebDAV correctly assumes this determination is up to the editor.  
>> Since this is a perfectly reasonable fallback means of updating an Atom 
>> Entry 
>> Document when it is desirable to give this control to the editor, all the 
>> more reason to make sure that APP supports Atom-specific manipulations.
>
>Hu?
>
>The ETag always is assigned by the server. There's no way in plain HTTP 
>or WebDAV to update a resource via PUT and let the editor claim that 
>it's an insignificant change.
>

An editor can use WebDAV to PUT a new resource at a location, including a new 
<updated> value, regardless of what any publishing system wants.  You're 
getting my point backwards, btw.  I'm saying exactly what you just said -- 
there is indeed no way in plain ol' HTTP to let the editor claim it's an 
insignificant change -- _all_ edits MUST count as significant.  Atom Format 
says _no_ edits MUST count as significant.

>
>If the server decides that the new content isn't really different (for 
>instance because whitespace between XML attributes was changed, but the 
>server stores the data in an XML-specific store anyway), it has the 
>choice not to assign a new ETag.
>

That's exactly right.  The editor has no way of knowing if his most recent 
change resulted in a new cache-control setting.  So how to confirm the edit 
on retrieval?  By forcing a revalidation.  Unless the server hasn't changed 
its cache-control settings, because the server owner/publisher has deemed it 
an insignificant change.  In which case what does the user do with what 
appears to be a lost edit, when in fact it was accepted with the appropriate 
200 OK response but whose message body contains the same cached version the 
editor started with?

>> Here's the example:  I'm generating summaries elsewhere on my site using the 
>> placement of the <p/> tag (just for the sake of the example, although re-
>> serializing the XML is another example of an insignificant change) but this 
>> has absolutely no effect on any request for the full-content representation. 
>
>Clarifying: you mean for those who read a transformed HTML version?
>

Not just them, what about everyone who subscribes to the feed whose content 
and updated values haven't changed but whose eTag (mysteriously to them) has? 
Only the writable GET representation of the Member resource needs to be 
changed in the case of insignificant edits, not the otherwise-perfectly-
cacheable read-only representation.

>> The only consumers of this Atom Entry Document are readers who don't care 
>> about that <p/> tag and editors who do very much care about that <p/> tag.
>> 
>> http://canuck.bisonsystems.net/dev/atom/entry-client-2.xml
>> 
>> Without some differntiating mechanism, every time an editor changes the 
>> location of that <p/> tag will be de facto considered a significant change 
>> even if I as the publisher have determined that it will not change the value 
>> of <updated>.  So for the purpose of reading that Atom Entry Document, the 
>
>It will be considered a content change on the HTTP level, that is the 
>content is refetched; but on the Feed Reading level, it shouldn't show 
>up unless atom:updated indeed changed as well. That seems to be 
>completely ok to me.
>

At the <feed> level everything's AOK.  But, when the feed reader fetches that 
standalone <entry> it's going by the cache-control headers.  So why should an 
insignificant edit that this user won't even see reflected in his 
representation be forced to round-trip my server when what he gets is no 
different that what the last user got?  See my scaling problem here?  Most 
web visits aren't by editors, they're by readers, so you can't invalidate the 
reader cache for insignificant edits without breaking any Atom implementation 
which uses <updated> as the basis for cacheing.

>> previously-cached version whose eTag value was equal to atom:id+atom:updated 
>> remains the publisher's choice for the feed and any other resource on any 
>> other website derived from that feed.
>
>I do agree that id+updated doesn't make a very good ETag, so why don't 
>you assign something better?
>

What I'm saying is that id+updated makes a _perfectly_ good eTag, if I wasn't 
trying to implement APP alongside it what would be wrong with it?  Please 
don't make Atom Format implementers break their cache strategy in order to 
support the Atom Publishing Protocol.

-EJB

>> I could go on, let me know how I should, what's not clear etc.
>
>Best regards, Julian
>