RE: Method for a client to determine if what it PUT/POSTed will be the same as what it would GET

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Teo Hui Ming wrote:
> On Jan 29, 2008 10:49 PM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
> > Even if the server is trying to keep them in sync, you 
> cause problems when the entry is being cached in such a way 
> that the MD5 hash and ETag are stale. You have to do a HEAD 
> on the media resource to (attempt to) verify that the media 
> link entry is up-to-date.  If you have to do a HEAD request 
> and you are depending on the server to calculate an MD5 hash 
> anyway, then why not just depend on the server to send a 
> Content-MD5 in response to the HEAD request?
> 
> Agree. :-) Given that an AtomPub client will be programmed to send out
> Content-MD5 header when PUT/POST a media resource, then 
> sending a subsequent HEAD by assuming server will return a 
> Content-MD5 header in response. The assumption is implicitly 
> made by client. Will it be worth to make this assumption 
> explicit, probably announced by server, e.g. label a media 
> collection with specific f:feature?

This is something that a server can implement accidently. If the server generates Content-MD5 headers anyway (like Amazon S3 does), then it will automatically work. That means that the absense of the flag wouldn't imply that this protocol won't work for that server. Similarly, if the flag is present in the service document, but the server doesn't actually send the (correct) Content-MD5 header, then the client can continue on according to the protocol anyway. So, the only real useful flag would be a "I promise you I won't give you the Content-MD5/ETag pair that you want" flag. It doesn't sound very practical.

Note that this mechanism is also useful for the case when the edit-media IRI doesn't match the content/@src IRI, to tell if the resources at those two locations have the same content. 

- Brian