Comments on: Location vs. Content-Location

By: BigSmoke » Atom and REST

BigSmoke » Atom and REST — Tue, 03 Nov 2009 17:23:28 +0000

[...] looking at the trackbacks of that post, I came across a very nice post by Subbu detailing the differences between and uses of the Location and Content-Location HTTP headers. « Back to top » Skip to navigation By Rowan Rodrik | On October 09, 2009 at 23:10 [...]

By: Kris Zyp

Kris Zyp — Wed, 29 Oct 2008 16:28:49 +0000

Yes, I was aware that I could do this with PUT requests, but I wanted to defer to the server’s URI assignment (and therefore use POST). The Slug header sounds like a good idea, I don’t think a guarantee is necessary, I just wanted an unobtrusive way for the client to communicate such links when necessary. Thank you.

By: Subbu Allamaraju

Subbu Allamaraju — Wed, 29 Oct 2008 15:49:33 +0000

Have you considered using PUT instead to create both A and B. A server can let PUT to create new resources when it can can "name" resources. Here is a possible flow.

PUT /mypath/a

…

PUT /mypath/b

…

However, a problem with this model is that it creation of B fails, A will have a stale link to A, and so, the client will have to do another PUT to update A to remove that stale link.

Alternatively you can you use AtomPub-style "Slug" header, but there is no guarantee (for the client, i.e.,) that the server will use that header while naming the new resource.

By: Kris Zyp

Kris Zyp — Wed, 29 Oct 2008 03:30:58 +0000

In the past I have attempted (incorrectly I assume) to use Content-Location in a POST request so the client can indicate where it would like the resource to be temporarily be addressable until it receives a server-assigned URI (in the response). The use case:
Suppose I want to create resource A and resource B, both through POST requests (so the server can assign the URI), and I want to resource A to be have a link to resource B, and have resource B have a link to resource A (and I am assuming that the server can update the internal links if an alternate URI is used prior to receiving a server assigned URI). Is there a way to do this properly with HTTP?

By: Bill Burke

Bill Burke — Tue, 07 Oct 2008 04:50:42 +0000

My example was using Content-Location as a header within a multipart response of a GET and, I think, satisfies the paragraph you quoted. In fact the multipart RFC states:

“The only header fields that have defined meaning for body parts are those the names of which begin with “Content-”. All other header
fields may be ignored in body parts. Although they should generally
be retained if at all possible, they may be discarded by gateways if
necessary.”

Its highly probable nobody has ever used Content-Location within a body part. Still, I’d much rather create and define my own headers then have to parse a heavyweight envelope format like Atom, which was my original point.

BTW, HTTP 1.1 does not forbid using Content-Location within a PUT or POST, but it does state that the behavior is undefined.