Core: Better HTTP headers

[teohhanhui]

For example, when a resource is created, we're not sending the correct HTTP headers in the response.

Location

For 201 (Created) responses, the Location value refers to the primary
resource created by the request. For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for
automatically redirecting the request.

https://tools.ietf.org/html/rfc7231#section-7.1.2

Content-Location

If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient
MAY consider the payload to be a current representation of that
resource at the time indicated by the message origination date. For
a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the
same as the default semantics when no Content-Location is provided by
the server. For a state-changing request like PUT (Section 4.3.4) or
POST (Section 4.3.3), it implies that the server's response contains
the new representation of that resource, thereby distinguishing it
from representations that might only report about the action (e.g.,
"It worked!"). This allows authoring applications to update their
local copies without the need for a subsequent GET request.

If Content-Location is included in a 2xx (Successful) response
message and its field-value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is
an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically
determined via HTTP.

• For a response to a GET or HEAD request, this is an indication
  that the effective request URI refers to a resource that is
  subject to content negotiation and the Content-Location
  field-value is a more specific identifier for the selected
  representation.

• For a 201 (Created) response to a state-changing method, a
  Content-Location field-value that is identical to the Location
  field-value indicates that this payload is a current
  representation of the newly created resource.

• Otherwise, such a Content-Location indicates that this payload is
  a representation reporting on the requested action's status and
  that the same report is available (for future access with GET) at
  the given URI. For example, a purchase transaction made via a
  POST request might include a receipt document as the payload of
  the 200 (OK) response; the Content-Location field-value provides
  an identifier for retrieving a copy of that same receipt in the
  future.

https://tools.ietf.org/html/rfc7231#section-3.1.4.2

[teohhanhui]

So, for example, if I do:

POST /books
Content-Type: application/ld+json
Accept: application/ld+json
---
{ ... request body ... }

I might expect to get:

201 Created
Location: /books/1
Content-Location: /books/1
Content-Type: application/ld+json
---
{ ... response body ... }

[dunglas]

Are we sure that most common browsers will not follow the provided Location header? If yes, then 👍

[jewome62]

@teohhanhui Could be close ?

[soyuka]

thanks @jewome62