Re: Why MD5 Headers are Imperative

Eric J. Bowman schrieb:
> > > 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.
>
> Maybe I'm misreading the spec, but I thought it said after a PUT the response 
> should include the Content-Location of the Member URI.

Can't see that in 
<http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-09.html#rfc.section.5.3.2>.

> If an editor is changing something the server deems insignificant, then that 
> change is not transformed to the still-current-and-unchanged-by-the-edit 
> read-only representation.  Since the intent was to alter the _writable_ 
> representation which is separately cached with my solution, the client may 
> dereference the URL in Content-Location _with_ an "X-APP-MD5" header which 
> will retrieve the updated writable representation.

Well, all this seems to depend on a distinction that you have invented 
(maybe for good reasons), but as far as I can tell is not in the spec.

You do a PUT to a member resource, and this changes it. There's no 
decoupling from a "read only" URI (per the spec).

> > > 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.
>
> Because the server never transforms the insignificant edit into the static, 
> read-only version whose cacheing is based on etag=atom:id+atom:updated, never 
> updates that eTag, and will cause even a revalidation request to return 304.

I have trouble following. You seem to argue based on a very specific 
approach to APP, maybe spec-compliant, maybe not. It seems you say "I'm 
doing X, and thus have to solve problem Y". I'm interested more in why 
you're doing X, not in solving Y which may be just caused by doing X in 
the first place.

> "Except for additional traffic and delay" for one user turns into a real 
> scalability nightmare on the server.  What I'm saying is that this problem 
> will be so frequent that the spec is addressing the 20, not the 80, of 80/20. 
> Because the least-frequent GET request will be coming from an APP client, why 
> should the least-likely use case invalidate the cache strategy which was 
> designed on the premise of the most-likely use case of read-only?

Maybe I'm missing something, but feed readers by default read the feed, 
not the individual members. As long as the ETag of the *feed* doesn't 
change, why would there ever be a subsequent request to refresh a member?

> > 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.
>
> Check your assumptions, please.  :)  If I set up a read-only Atom 
> implementation then I'm not doing _any_ edits, am I?  Therefore the logical, 
> intuitive and obvious cacheing solution for this use case is eTag=atom:id+
> atom:updated, in perfect compliance with HTTP 1.1.

No, it's not. RFC2616 very clearly says that the ETag (when strong) MUST 
change if the contents of the resource changes.

> All you're saying is if I want to comply with APP I have to de-comply with 
> HTTP, or re-code my entire application based on the assumption that <updated> 
> means something different than what RFC 4287 says it means.

No, what I'm saying is that RFC2616 defines the ETag response header, 
and RFC4287 defines atom:updated, and that there is no problem complying 
to both unless you (ab)use atom:updated to compute ETags.

Best regards, Julian