Cabeçalhos HTTP e CORS
É comum que alguns clientes criem regras de Smart Rule com o critério sendo alguma URL e a ação sendo “Define cabeçalho de resposta”, configurando cabeçalhos que diferem apenas em letras maiúsculas e minúsculas, por exemplo: Access-Control-Allow-Origin ou access-control-allow-origin.
No protocolo HTTP, os nomes dos cabeçalhos não diferenciam maiúsculas e minúsculas, ou seja, “Content-Type”, “content-type” e “CONTENT-TYPE” são tratados como equivalentes. No entanto, em contextos de CORS (Cross-Origin Resource Sharing), o navegador compara os valores literais de certos cabeçalhos, como parte da validação do preflight, o que significa que esse processo é case-sensitive (letras maiúsculas são consideradas diferentes de minúsculas).
Esse detalhe pode gerar um problema de bloqueio se os valores forem alterados pela GoCache.
Exemplo de fluxo problemático
O navegador faz uma requisição preflight (método OPTIONS). Essa requisição não é cacheada pela GoCache por padrão e é enviada diretamente ao servidor de origem. O navegador então armazena a resposta recebida por ele.
Em seguida, o navegador envia a requisição real (por exemplo, POST ou GET) e compara os cabeçalhos com o que foi respondido na preflight.
Porém, se houver uma regra de Smart Rule que altera os valores dos cabeçalhos de resposta, quando o critério dela for atendido, os valores dos cabeçalhos serão alterados. Se neste caso o que estiver definido na Smart Rule for diferente do que está definido no servidor de origem, o CORS vai identificar uma inconsistência e bloquear a requisição.
Por exemplo, o navegador envia o que o cliente está tentando receber/enviar, para saber se o servidor aceita:
Access-Control-Request-Headers: Content-Type, Authorization
Então, ele espera que o servidor responda com exatamente os mesmos valores, na mesma capitalização.
Access-Control-Allow-Headers: Content-Type, Authorization
Porém, a Smart Rule da GoCache (caso esteja com case diferente da respondida pelo servidor), alterará os cabeçalhos da resposta que chegarão ao navegador para algo como:
Access-Control-Allow-Headers: content-Type, authorization
O navegador, ao detectar a diferença de capitalização nos valores, bloqueará a requisição por não corresponder exatamente ao que o servidor permitiu.
Preflight e requisições simples
Uma requisição preflight de CORS é feita com método OPTIONS e verifica se o protocolo CORS é entendido e se o servidor aceita o método, os cabeçalhos e, se aplicável, o envio de credenciais (cookies, autorização, etc.). Essa requisição é feita antes da requisição real quando ela é considerada “não-simples”.
Uma requisição simples inclui métodos HTTP comuns e apenas um conjunto limitado de tipos de conteúdo (content-type). Essas requisições não acionam solicitações preflight e podem ser enviadas diretamente ao servidor sem uma validação prévia.
Uma requisição simples inclui apenas:
Métodos HTTP GET, HEAD ou POST
Content-Type igual a “application/x-www-form-urlencoded”, “multipart/form-data” ou “text/plain”.
Cabeçalhos CORS-safelisted, como “Accept”, “Accept-Language” ou “Content-Language”
Qualquer requisição que fuja desse padrão (por exemplo, um POST com application/json ou com cabeçalhos customizados) gerará uma requisição preflight.
Por exemplo, uma requisição de login comum:
POST /api/login HTTP/1.1
Host: api.exemplo.com
Origin: https://app.cliente.com
Content-Type: application/json
Authorization: Bearer 123
Nesse caso, o navegador disparará o preflight porque:
Content-Type é application/json (não é um dos três permitidos para requisições simples)
Existe o cabeçalho customizado Authorization
Requisição preflight que o navegador fará:
OPTIONS /api/login HTTP/1.1
Host: api.exemplo.com
Origin: https://app.cliente.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization
Resposta esperada do servidor:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.cliente.com
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
Mensagens de erro
Mensagens de erro de CORS geralmente indicam que a requisição preflight falhou, mas não detalham especificamente todos os erros ocorridos. Isso ocorre porque o navegador exibe apenas mensagens genéricas por segurança; ele não revela detalhes internos da resposta do servidor, para evitar que scripts maliciosos descubram configurações de CORS e usem isso como vetor de ataque.
Na prática, o máximo de precisão obtida é o tipo de falha reportado (por exemplo, falta de Access-Control-Allow-Origin, método não permitido em Access-Control-Allow-Methods, cabeçalho não aceito em Access-Control-Allow-Headers). Para depuração mais profunda, é necessário inspecionar manualmente os cabeçalhos da requisição OPTIONS e da resposta na aba “Network” das ferramentas do navegador.
Exemplo inválido:
Preflight do navegador:
Access-Control-Request-Headers: Content-Type, Authorization
Resposta à requisição:
Access-Control-Allow-Headers: content-type, authorization
A requisição é bloqueada, pois a comparação literal falha e o navegador retornaria algo como:
Access to XMLHttpRequest at 'https://api.exemplo.com/api/login' from origin 'https://app.cliente.com' has been blocked by CORS policy: Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
Porém, observe que o cabeçalho Authorization também está errado e não foi informado na mensagem de erro. Sendo assim, note que essas mensagens não são absolutamente precisas.
Diagnóstico de erros de CORS durante o Preflight
Abra o DevTools do navegador → aba Network → selecione a requisição OPTIONS.
Observe os cabeçalhos enviados pelo navegador na preflight:
Analise se os valores configurados na Smart Rule correspondem exatamente (inclusive em letras maiúsculas/minúsculas) aos valores retornados pelo servidor de origem. Observe os cabeçalhos Access-Control-Request-Method e Access-Control-Request-Headers, principalmente.
Corrija a configuração conforme o diagnóstico:
Ajuste a Smart Rule que sobrescreve cabeçalhos CORS sensíveis.
Garanta que em sua regra estejam definidos os valores dos cabeçalhos exatamente como seu servidor de origem os retorna.
Evite múltiplas definições do mesmo cabeçalho no painel da GoCache.
Caso fique com dúvidas, entre em contato com o nosso suporte. Teremos prazer em ajudá-lo.
E-mail: suporte@gocache.com.br.