Re: Why MD5 Headers are Imperative

Eric J. Bowman schrieb:
> > 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.

Well, I think everything will be much simpler if they are. It seems to 
me that you're trying to optimize for a use case that doesn't need 
optimization.

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

Yes. So ETag (as HTTP cache validator) and app:updated (as something 
that can signal whether a feed reader should "redisplay" the entry) are 
very different things. This seem to be perfectly ok.

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

Why would it need to know? You do a PUT, the server says 200, so the 
content has been stored. If you're lucky, you also get a new ETag in the 
response.

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

Why would it contain that? I'm not sure why that would happen.

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

Well, you will have clients refetch the contents although this wouldn't 
have been necessary. It will not affect the user experience, except for 
additional traffic/delay. How frequently are you doing these kinds of 
changes requiring the protocol to come up with a custom "fix" for that?

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

I think I now do understand what's going on, but I'm absolutely not 
convinced that it's a problem in practice.

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

HTTP defines how an ETag needs to behave. Well, at least for strong ETags.

If you use id+updated as a strong ETag, and do non-significant edits on 
the resource, causing the ETag to stay the same, then you're not 
compliant to HTTP. Thus, id+updated can't be used as ETag unless you 
change "updated" with every change, which would defeat it's original 
purpose.

Best regards, Julian