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 julho de 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
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.
<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
Loading…