O que é uma solicitação de pré-vôo? Verificações de CORS OPTIONS explicadas

A Scrapeless Universal Scraping API recupera conteúdo público da web permitido e pode renderizar JavaScript quando a Solicitação de Pré-vôo deve ser observada em uma resposta real.

TL;DR

A Solicitação de Pré-vôo tem um papel de protocolo preciso. Uma solicitação de pré-vôo é uma verificação automática de CORS na qual um navegador envia uma solicitação OPTIONS antes de certas solicitações de origem cruzada.
A Solicitação de Pré-vôo deve ser lida na camada correta. Transporte, representação, política do navegador e autorização de aplicativo permanecem preocupações separadas.
Intermediários podem mudar o que um aplicativo observa. Gateways, caches, padrões do navegador e bibliotecas de clientes podem adicionar processamento entre bytes de origem e dados analisados.
A validação precisa de evidências de conteúdo. Um status ou campo isolado não prova que a representação pública esperada chegou.
A segurança depende de escopo e validação. A sintaxe do protocolo nunca concede permissão para acessar um recurso ou confiar em um valor fornecido por um chamador.

O que é a Solicitação de Pré-vôo?

Uma solicitação de pré-vôo é uma verificação automática de CORS na qual um navegador envia uma solicitação OPTIONS antes de certas solicitações de origem cruzada. A pré-vôo identifica a origem do chamador, o método pretendido e os nomes dos campos de solicitação não seguros. A resposta do servidor informa ao navegador se ele pode enviar a solicitação real; a pré-vôo não executa essa operação pretendida do aplicativo.

A definição útil inclui tanto o mecanismo quanto seu limite. A Solicitação de Pré-vôo afeta uma parte específica de uma troca, enquanto responsabilidades adjacentes permanecem com HTTP, o navegador, o transporte selecionado, o aplicativo ou o modelo de dados do servidor. Manter essas camadas separadas torna os relatórios de erro reproduzíveis e evita que uma mudança de configuração seja confundida com uma decisão de controle de acesso.

Para desenvolvedores de API, a primeira pergunta é quem cria o valor ou comportamento. A próxima pergunta é quem o interpreta. A pergunta final é qual resultado observável prova que a interpretação funcionou. Essas três respostas transformam um termo de glossário em um contrato de interface testável.

A verificação OPTIONS antes da solicitação real

O navegador classifica uma busca de origem cruzada com base em seu método, campos controlados pelo autor e tipo de conteúdo. Se a solicitação estiver fora da forma segura do CORS, o navegador cria uma solicitação OPTIONS para a URL de destino em vez de enviar imediatamente o método do aplicativo.

A origem identifica a página que está chamando. Access-Control-Request-Method nomeia o método planejado, e Access-Control-Request-Headers lista os nomes dos campos de solicitação relevantes não seguros. A pré-vôo não carrega o corpo da solicitação real, e as regras normais do Fetch dizem que as solicitações de pré-vôo CORS excluem credenciais.

O servidor ou gateway retorna Access-Control-Allow-Origin mais permissões de método e campo que cobrem a troca planejada. Ele também pode retornar Access-Control-Max-Age para que o navegador possa armazenar em cache um resultado de pré-vôo bem-sucedido dentro dos limites de implementação.

Somente depois que a política corresponde, o navegador envia a solicitação real. Essa segunda resposta também deve levar a permissão apropriada de CORS. Passar OPTIONS, mas omitir campos na resposta real, ainda produz uma falha visível para o navegador.

Lendo um par de pré-vôo

Os seguintes termos separam os componentes que muitas vezes são agrupados em um único rótulo. Leia-os como interfaces entre participantes, em vez de como decoração em uma trilha de rede.

OPTIONS

O método HTTP usado para a verificação de política, não o método de negócios que a página quer invocar.

Origem

A origem da página que solicita acesso de origem cruzada.

Access-Control-Request-Method

O método real planejado para a solicitação posterior.

Access-Control-Request-Headers

Os nomes dos campos de solicitação do autor não seguros planejados para a solicitação posterior.

Access-Control-Allow-Methods

Os métodos que o servidor aprova para essa origem e contexto de recurso.

Access-Control-Max-Age

Uma duração para armazenar em cache a permissão de pré-vôo bem-sucedida, sujeita a limites do navegador e regras de cache.

Por que a Solicitação de Pré-vôo é importante na Coleta de Dados da Web

A Solicitação de Pré-vôo pode mudar quais bytes chegam, como esses bytes são interpretados ou se o código do navegador pode observar o resultado. Um fluxo de trabalho de coleta deve localizar esse efeito antes de mudar ferramentas. Registre a URL solicitada, URL final, status da resposta, tipo de representação, campos de protocolo relevantes e um marcador de conteúdo esperado. Esse registro compacto distingue uma página correta de uma mensagem de acesso, tela de consentimento, alvo de redirecionamento, shell de aplicativo vazio ou codificação incompatível.

HTTP direto é o caminho de aquisição mais simples quando os dados necessários existem em uma resposta renderizada em servidor aberto. Um navegador se torna relevante quando o conteúdo aprovado depende da execução de JavaScript, estado gerenciado pelo navegador, navegação ou política de segurança do navegador. Os dois caminhos não devem ser forçados a parecer idênticos: os navegadores gerenciam cookies, compressão, redirecionamentos, CORS e armazenamento de acordo com regras de plataforma, enquanto um cliente direto expõe um conjunto diferente de padrões.

A continuidade da sessão é importante sempre que uma resposta estabelece estado para a próxima solicitação. Mantenha uma sequência autorizada dentro de um único contexto de cliente limitado, preserve o local necessário e a origem da rede, e evite misturar estados de trabalhos não relacionados. Um proxy muda a origem da rede; ele não reproduz cabeçalhos, decodifica representações, executa scripts ou concede acesso a conteúdo restrito.

A análise começa apenas após a validação da representação. Confirme o host final, a identidade canônica onde disponível, o tipo de mídia, o estado de decodificação e o marcador de negócios necessário antes de extrair campos. Essa ordem evita que um analisador transforme um documento de erro em registros vazios que parecem tecnicamente bem-sucedidos.

Os intermediários merecem atenção explícita. Uma rede de entrega de conteúdo pode selecionar uma variante codificada, um gateway pode responder a OPTIONS, um cache pode reutilizar uma resposta negociada e um servidor de aplicação pode definir cookies ou campos de autorização.

API de Scraping Universal Sem Resíduos é relevante quando uma equipe precisa de recuperação gerenciada de conteúdo público permitido, incluindo páginas renderizadas em JavaScript. O contrato de aquisição ainda deve definir o alvo, campos permitidos, representação esperada, marcador de aceitação e condições de parada. A capacidade do produto não substitui os termos da fonte, revisão de privacidade ou validação a nível de aplicação.

Solicitações que normalmente acionam a Solicitação Preliminar

A Solicitação Preliminar ganha um lugar em uma arquitetura quando muda um comportamento concreto do produto, requisito de compatibilidade ou decisão de diagnóstico. Esses casos de uso descrevem o trabalho primeiro e o recurso do protocolo em segundo.

Escrita JSON

Um POST de origem cruzada usando application/json normalmente está fora da forma de solicitação autorizada.

Campo de autorização personalizado

Campos controlados pelo autor fora da lista autorizada fazem com que o navegador peça permissão primeiro.

PUT ou DELETE

Métodos fora do conjunto autorizado normalmente requerem uma verificação OPTIONS.

Campo de rastreamento personalizado

Um campo de id de solicitação adicionado pela página pode mudar uma solicitação direta em uma troca preliminar.

API de Upload

O método e o tipo de mídia escolhidos determinam se uma verificação de política separada ocorre.

Console multi-origem

Um frontend administrativo em uma origem pode pré-processar chamadas para uma API de origem distinta.

Solicitações Pré-processadas e CORS-Autorizadas

A Solicitação Preliminar pertence a uma camada do HTTP e não deve ser confundida com camadas adjacentes. Uma implementação sólida identifica qual componente seleciona o valor, qual componente pode alterá-lo e quais evidências provam que a representação final está correta.

Dimensão	Solicitação Preliminar	Conceito relacionado ou alternativo
Método	Pode incluir PUT, DELETE ou outros métodos	GET, HEAD ou POST dentro das regras da lista autorizada
Campos de autor	Inclui um campo não autorizado	Somente campos de autor autorizados
Tipo de conteúdo	Frequentemente application/json ou outro tipo não autorizado	Tipo de mídia autorizado com restrições de parâmetros
Passo do navegador	A verificação OPTIONS precede a solicitação real	A solicitação real pode ser enviada diretamente
Segurança do servidor	Autenticação e autorização ainda necessárias	Autenticação e autorização ainda necessárias

Uma comparação é útil apenas se preservar os limites das camadas. Dois mecanismos podem coexistir em uma solicitação, e substituir um não substitui automaticamente o outro. Documente o comportamento selecionado em termos de entradas, saída observável, estado de falha e propriedade.

Por que o Manipulador Preliminar Quebra

Roteamento OPTIONS para nenhum manipulador. Gateways e estruturas podem retornar um erro genérico antes que a lógica CORS da aplicação seja executada.
Permitindo o método, mas não o campo. O método planejado e cada campo não autorizado solicitado devem ser cobertos.
Exigindo credenciais ordinárias em OPTIONS. O comportamento de pré-processamento não inclui credenciais normais de solicitação.
Esquecendo a resposta real. Ambos a verificação de permissão e a resposta posterior precisam da política de origem aplicável.
Depuração apenas dos logs da aplicação do servidor. Um CDN, proxy ou servidor web pode responder OPTIONS antes que a aplicação o veja.
Desabilitando um campo de solicitação necessário. Remover campos de segurança ou conteúdo para evitar o pré-vôo pode danificar o contrato da API.

A maioria das falhas se torna mais fácil de diagnosticar após remover suposições sobre o que uma biblioteca ou navegador fez automaticamente. Capture uma trilha mínima, redija segredos e altere uma variável controlada de cada vez. O objetivo é uma explicação estável da representação retornada, não uma coleção de ajustes de cabeçalho não relacionados.

Uma Lista de Verificação de Falhas de Pré-vôo

Esta sequência funciona como uma revisão de design antes do lançamento e como um diagnóstico de produção após mudanças no comportamento. Ela mantém a evidência do protocolo conectada ao resultado da aplicação.

Identifique a origem da página, a origem de destino, o método planejado, o tipo de conteúdo e os campos controlados pelo autor.
Abra a troca OPTIONS e leia seus campos de status e resposta sem supor que a aplicação o manipulou.
Corresponda Access-Control-Allow-Origin à origem da solicitação sob as regras de credenciais.
Confirme que Access-Control-Allow-Methods inclui o método planejado.
Confirme que Access-Control-Allow-Headers cobre todos os nomes de campo não listados como seguros solicitados.
Verifique redirecionamentos, proxies e manipuladores de erro para respostas que omitem campos CORS.
Após OPTIONS passar, inspecione a solicitação e a resposta reais como uma troca separada.

Termine a revisão salvando uma pequena amostra aceita e uma amostra rejeitada com as mesmas regras de redação. Mudanças futuras podem então ser comparadas com a identidade da página conhecida, campos esperados e conteúdo decodificado em vez de memória ou capturas de tela apenas.

Segurança e Observabilidade para a Solicitação de Pré-vôo

A Solicitação de Pré-vôo participa de um caminho de solicitação que pode cruzar navegadores, gateways, caches e servidores de origem. Cada salto deve aceitar apenas os valores que compreende, preservar os campos que devem sobreviver e evitar copiar credenciais ou dados pessoais para logs. A sintaxe do protocolo não é autorização.

Registros operacionais devem capturar a URL solicitada, URL final, status, tipo de representação, nomes de campos relevantes e um marcador de conteúdo limitado. Corpos completos e valores de credenciais raramente são necessários para diagnóstico rotineiro e podem criar risco de retenção desnecessário.

Comportamento do navegador e comportamento HTTP direto são superfícies de teste diferentes. CORS, armazenamento de cookies, descompressão automática e manipulação de redirecionamento podem ser realizados pelo navegador ou biblioteca antes que o código da aplicação veja um resultado. Registre o cliente e seus padrões ao comparar capturas.

Padrões Que Definem a Solicitação de Pré-vôo

o algoritmo de pré-vôo do Padrão Fetch define a verificação de política do navegador. Esta fonte primária corrige o vocabulário e a fronteira usados neste artigo, enquanto o comportamento de implementação ainda precisa ser observado no cliente e no ambiente selecionados.

o glossário de solicitações de pré-vôo do MDN mostra os campos da solicitação OPTIONS. Esta fonte primária corrige o vocabulário e a fronteira usados neste artigo, enquanto o comportamento de implementação ainda precisa ser observado no cliente e no ambiente selecionados.

o guia CORS do MDN explica as restrições de pré-vôo e credenciais. Esta fonte primária corrige o vocabulário e a fronteira usados neste artigo, enquanto o comportamento de implementação ainda precisa ser observado no cliente e no ambiente selecionados.

a semântica HTTP OPTIONS define o método HTTP subjacente. Esta fonte primária corrige o vocabulário e a fronteira usados neste artigo, enquanto o comportamento de implementação ainda precisa ser observado no cliente e no ambiente selecionados.

A Regra de Depuração de Pré-vôo

Trate o pré-vôo e a solicitação real como duas trocas HTTP separadas e verifique comportamento de origem, método, campo, credencial, gateway e resposta final no nível que produziu cada resposta.

Coloque essa regra em um teste de aceitação. Declare qual participante envia o sinal, qual participante o interpreta, quais intermediários podem alterar o caminho e qual marcador de conteúdo prova o sucesso. Isso torna a Solicitação de Pré-vôo parte de um sistema observável em vez de um rótulo anexado após uma falha.

Pronto para Validar uma Resposta Web Pública?

Use a Scrapeless Universal Scraping API para recuperar conteúdo público aprovado e verificar o contrato de representação descrito neste guia.

Inscreva-se hoje e ganhe $5 em crédito grátis — nenhum cartão de crédito necessário.

Reivindique seu crédito de $5 →

Perguntas Frequentes

Os desenvolvedores enviam solicitações de pré-vôo manualmente?

Normalmente não. O navegador cria e envia um pré-vôo CORS automaticamente quando a solicitação planejada de origem cruzada requer um. Chamadas OPTIONS manuais são úteis apenas para diagnóstico e não reproduzem todas as decisões do navegador.

Uma solicitação de pré-vôo é a mesma que a solicitação real da API?

Não. O pré-vôo é uma verificação de permissão OPTIONS. O método e o corpo reais são enviados somente após o navegador aceitar a resposta da política.

Por que application/json aciona o pré-vôo?

Uma solicitação de origem cruzada feita por autoria da página usando application/json não se encaixa na forma de tipo de conteúdo listado como seguro pelo CORS, então o navegador normalmente verifica a permissão antes de enviá-la.

Os resultados do pré-vôo podem ser armazenados em cache?

Sim. Uma resposta bem-sucedida pode incluir Access-Control-Max-Age, e o navegador pode armazenar em cache essa permissão dentro de seus próprios limites. O cache é separado do cache normal de resposta HTTP.

Um endpoint OPTIONS deve exigir login?

Um pré-vôo CORS não inclui credenciais de solicitação normais sob as regras do Fetch. O endpoint deve responder à verificação de política enquanto a operação real ainda impõe autenticação e autorização.