Access-Control-Allow-Headers
O cabeçalho de resposta Access-Control-Allow-Headers
é usado na resposta à uma preflight request na qual incluí o cabeçalho Access-Control-Request-Headers
para indicar quais cabeçalhos HTTP podem ser utilizados durante a requisição efetiva.
Este cabeçalho é obrigatório se a requisição tem um cabeçalho Access-Control-Request-Headers
.
Tipo de cabeçalho | Response header |
---|---|
Forbidden header name | não |
Sintaxe
Access-Control-Allow-Headers: <nome-do-cabeçalho>[, <nome-do-cabeçalho>]* Access-Control-Allow-Headers: *
Diretivas
<nome-do-cabeçalho>
-
O nome de um cabeçalho suportado. O cabeçalho pode listar qualquer quantidade de cabeçalhos, desde que sejam separados por vírgula.
*
(coringa)-
O valor "
*
" só conta como um valor coringa para requisições sem credenciais (requisições sem cookies HTTP ou informação de autenticação HTTP). Em requisições com credenciais, isso é tratado como o nome de cabeçalho literal "*
" sem qualquer semântica especial. Note que o cabeçalhoAuthorization
não pode utilizar um coringa e sempre precisa ser listado explicitamente.
Os cabeçalhos CORS-safelisted request headers, Accept
, Accept-Language
, Content-Language
, Content-Type
são sempre permitidos e não precisam ser listados por este cabeçalho necessariamente. Entretanto, note que restrições adicionais são aplicadas com estes cabeçalhos envolvidos por listar estes cabeçalhos no cabeçalho Access-Control-Allow-Headers
também.
Exemplos
Um cabeçalho customizado
Aqui está um exemplos de como um cabeçalho Access-Control-Allow-Headers
pode se parecer. Isso indica que em adição aos CORS-safelisted request headers, um cabeçalho customizado chamado X-Custom-Header
é suportado por requisições CORS pelo servidor.
Access-Control-Allow-Headers: X-Custom-Header
Múltiplos cabeçalhos
Este exemplo mostra o cabeçalho Access-Control-Allow-Headers
quando é especificado para suportar diversos cabeçalhos.
Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
Burlando restrições adicionais
Apesar de que CORS-safelisted request headers são sempre permitidos e geralmente não precisam ser listados no cabeçalho Access-Control-Allow-Headers
, listá-los de qualquer forma irá envolver as restrições adicionais que são aplicadas.
Access-Control-Allow-Headers: Accept
Exemplo de requisição pré-vôo
Vamos dar uma olhada em um exemplo de requisição pré-vôo envolvendo o cabeçalho Access-Control-Allow-Headers
.
Requisição
Primeiro, a requisição. A requisição pré-vôo é uma requisição OPTIONS
que inclui algumas combinações de três cabeçalhos de requisições pré-vôo: Access-Control-Request-Method
, Access-Control-Request-Headers
, e Origin
, como por exemplo:
OPTIONS /resource/foo Access-Control-Request-Method: DELETE Access-Control-Request-Headers: origin, x-requested-with Origin: https://foo.bar.org
Resposta
Se o servidor permite requisições CORS para usar o método DELETE
, ele responde com um cabeçalho de resposta Access-Control-Allow-Methods
, no qual lista DELETE
junto à outros métodos suportados:
HTTP/1.1 200 OK Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: https://foo.bar.org Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE Access-Control-Max-Age: 86400
Se o método requisitado não é suportado, o servidor irá responder com um erro.
Especificações
Specification |
---|
Fetch Standard # http-access-control-allow-headers |
Compatibilidade com navegadores
BCD tables only load in the browser