Content-Location

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 (en-US)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 (en-US).

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.

<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

Especificaci贸n T铆tulo
RFC 7231, section 3.1.4.2: Content-Location Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Compatibilidad en navegadores

BCD tables only load in the browser

Ver tambi茅n