Content-Location
================

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 (en-US) (à URL da requisição) ou URL absoluta (en-US).

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 (en-US): `/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>` (en-US) 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 with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `Location`