Content-Location

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

La cabecera Content-Location indica una ubicación alternativa para los datos devueltos. Su principal uso es indicar la URL de un recurso transmitido y que ha resultado de una negociación de contenido.

Las cabeceras Location y Content-Location son diferentes. Location indica la URL de una redirección, mientras que Content-Location indica la URL directa a ser utilizada para acceder al recurso, sin necesidad de realizar negociación de contenido en el futuro. Mientras que Location es una cabecera asociada con la respuesta, Content-Location está asociada con los datos devueltos. Esta distinción puede parecer abstracta sin ver algunos ejemplos.

Header type	Entity header
Forbidden header name	no

Sintaxis

Content-Location: <url>

Directivas

<url>: Una URL relativa o absoluta (a la URL de la petición).

Ejemplos

Solicitando datos de un servidor en distintos formatos

Suponga que la API de un sitio web puede devolver datos en los formatos JSON, XML, o CSV. Si la URL de un documento particular se encuentra en https://example.com/documents/foo, el sitio web podría retornar distintas URLs en la cabecera Content-Location dependiendo de la cabecera Accept enviada en la petición:

Request header	Response header
`Accept: application/json, text/json`	`Content-Location: /documents/foo.json`
`Accept: application/xml, text/xml`	`Content-Location: /documents/foo.xml`
`Accept: text/plain, text/*`	`Content-Location: /documents/foo.txt`

Estas URLs son ejemplos — el sitio web podría servir los distintos tipos de ficheros con cualquier patrón de URL que desee, por ejemplo, por medio de un parámetro en la query: /documents/foo?format=json, /documents/foo?format=xml, y así sucesivamente.

De esa forma el cliente podrÍa recordar que la versión en formato JSON está disponible en esa URL particular, saltándose el paso de la negociación de contenido la próxima vez que solicite ese documento.

El servidor podría también considerar otras cabeceras de negociación de contenido, tales como Accept-Language.

Apuntando a un nuevo documento (HTTP 201 Created)

Suponga que está creando una nueva entrada de un blog, a través de la API del sitio web:

PUT /new/post
Host: example.com
Content-Type: text/markdown

# Mi primera entrada de blog!

Hice esto a través de la API de `example.com`'. Espero que funcione.

El sitio devuelve un mensaje genérico de éxito confirmando que el post ha sido publicado. El servidor especifica donde se encuentra la nueva entrada utilizando Content-Location:

HTTP/1.1 201 Created
Content-Type: text/plain; charset=utf-8
Content-Location: /my-first-blog-post

✅ Success!

Indicating the URL of a transaction's result

Digamos que tiene un formulario <form> para el envío de dinero a otro usuario de un sitio web.

html

<form action="/enviar-pago" method="post">
  <p>
    <label
      >A quien desea enviar dinero?
      <input type="text" name="destinatario" />
    </label>
  </p>

  <p>
    <label
      >Cuanto dinero?
      <input type="number" name="cantidad" />
    </label>
  </p>

  <button type="submit">Enviar dinero</button>
</form>

Cuando el formulario es enviado, el sitio web genera un recibo o comprobante de la transacción. El servidor podría utilizar la cabecera Content-Location para indicar la URL de ese comprobante para un acceso futuro.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Location: /mis-recibos/38

<!doctype html>
(Lots of HTML…)

<p>Ha enviado $38.00 a UsuarioFicticio.</p>

(Lots more HTML…)

Especificaciones

Specification
HTTP Semantics # field.content-location

Compatibilidad con navegadores

BCD tables only load in the browser

Ver también

Location