[Prev] Thread [Next]  |  [Prev] Date [Next]

RE: Content-Location matching Location for POST of a media resource Brian Smith Fri Dec 21 00:16:17 2007

Tim Bray wrote: 
> On Oct 16, 2007, at 1:16 PM, Brian Smith wrote:
> > RFC5023 (AtomPub), section 9.2 says:
> >
> > "If the creation request contained an Atom Entry Document,
> >  and the subsequent response from the server contains a
> >  Content-Location header that matches the Location header
> >  character-for-character, then the client is authorized to
> >  interpret the response entity as being a complete
> >  representation of the newly created Entry."
> > Why is the condition "if the creation request contained an
> > Atom Entry Document" there? Or, in other words, why is this
> > optimization not allowed for media link entries?

I found out the answer. RFC 2616 says:

    "If a resource has been created on the origin server, the
     response SHOULD be 201 (Created) and contain an entity which
     describes the status of the request and refers to the new
     resource, and a Location header (see section 14.30)."

In other words, this means that the media resource's URI (the
"edit-media" link) should be in the Location header, not the URI of the
media link. Thus, Content-Location and Location should never be
identical Content-Location will be the URI of the media link entry.

> Yep, I think this is a shortcoming in the spec. If I post a
> JPG and get back an MLE in the POST response, and want to
> update it with an updated version containing some more
> metadata about the JPG, I guess that I probably have to
> fetch the MLE again first; the protocol doesn't provide a
> way for the server to tell the client that the MLE is
> complete. This is silly since my suspicion is that
> typically, the MLE is initially going to be rather sparse,
> so why wouldn't the server send the whole thing back? In
> fact, the more I think about this, it seems like there's no
> bloody reason at all to send the MLE back unless you want the
> client to be able to use it. 

The media link has to be returned in order to satisfy the "contain an
entity which describes the status of the request and refers to the new
resource" requirement of RFC 2616.

> In fact, I guess that you'll probably get an ETag for the
> MLE, so you can just go ahead and try to update, and it'll
> probably work. -T