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.

O cabeçalho Content-Location indica uma localização alternativa para os dados retornados. O principal uso é para indicar o URL de um recurso transmitido como resultado de uma negociação de conteúdo.

Location e Content-Location são diferentes. Location indica o URL de um redirecionamento, enquanto Content-Location indica o URL direto usado para acessar o recurso, sem qualquer outra negociação de conteúdo no futuro. Location é um cabeçalho associado com a resposta, enquanto Content-Location é associado com os dados retornados. Essa distinção parece abstrata sem exemplos. Essa distinção pode parecer abstrata sem exemplos.

Tipo de cabeçalho	Entity header
Forbidden header name	no

Sintaxe

Content-Location: <url>

Diretivas

<url>: Uma URL relativa (à URL da requisição) ou URL absoluta.

Exemplos

Requerindo dados de um servidor em diferentes formatos

Digamos que uma API de um site pode retornar dados em formatos JSON, XML, ou CSV. Se a URL para um documento em particular está em https://example.com/documents/foo, o site pode retornar diferentes URLs para Content-Location dependendo do cabeçalho Accept nas requisições:

Cabeçalho de requisição	Cabeçalho de resposta
`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 são exemplos — o site pode servir diferentes formatos de arquivos com qualquer padrão URL que ele deseje, como por exemplo, um query string parameter: /documents/foo?format=json, /documents/foo?format=xml, entre outros.

Então o cliente pode lembrar que a versão JSON está disponível em uma URL em particular, evitando negociação de conteúdo da próxima vez que ele requerer aquele documento.

O servidor também pode considerar outros cabeçalhos de negociação de conteúdo, como o Accept-Language.

Apontando para um novo documento (HTTP 201 Created)

Digamos que você está criando um novo post no blog através da API do site:

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

# Meu primeiro post no blog!

Eu fiz através da API do `example.com`. Espero que ele tenha funcionado.

O site retorna uma mensagem de sucesso genérica confirmando que o post foi publicado. O servidor especifica onde o novo post está com Content-Location:

HTTP/1.1 201 Created
Content-Type: text/plain; charset=utf-8
Content-Location: /meu-primeiro-post-no-blog

✅ Sucesso!

Indicando a URL do resultado de uma transação

Digamos que você tem um <form> para enviar dinheiro para outro usuário do de um site.

html

<form action="/mandar-pagamento" method="post">
  <p>
    <label
      >Para quem você quer enviar o dinheiro?
      <input type="text" name="destinatario" />
    </label>
  </p>

  <p>
    <label
      >Quanto?
      <input type="number" name="quantidade" />
    </label>
  </p>

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

Quando o formulário é submetido, o site gera um recibo para a transação. O servidor pode usar Content-Location para indicar a URL do recibo para acesso futuro.

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

<!doctype html>
(Um monte de HTML…)

<p>Você mandou R$38.00 para UsuárioExemplo.</p>

(Mais um monte de HTML…)

Especificações

Especificação	Título
RFC 7231, sessão 3.1.4.2: Content-Location	Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Compatibilidade com navegadores

BCD tables only load in the browser

Veja também

Location