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.

> ...
> > 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.

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.

> 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?

> 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.

> 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?

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

Best regards, Julian