Testador de CORS

Continuar na ferramenta

Mais páginas desta ferramenta

preflight OPTIONS para PUT e JSON

Preflight CORS em requisições PUT/DELETE com JSON

Um simples PUT para atualizar um recurso, o padrão mais comum em qualquer API REST, sai da lista de "requisições simples" do CORS e obriga o navegador a mandar um OPTIONS de verificação antes.

Por que uma API REST "normal" quase sempre preflighta

O CORS define uma lista curta de "requisições simples": método GET, HEAD ou POST, sem headers além de um pequeno conjunto padrão, e com Content-Type limitado a application/x-www-form-urlencoded, multipart/form-data ou text/plain. Qualquer coisa fora dessa lista, um método PUT, PATCH ou DELETE, ou um POST com Content-Type: application/json (o formato de corpo mais comum em APIs REST modernas), obriga o navegador a enviar um OPTIONS de verificação antes da requisição de verdade.
Isso significa que praticamente toda API REST séria que aceita JSON dispara preflight em requisições de escrita, e o servidor precisa responder a esse OPTIONS com os headers Access-Control-Allow-Methods e Access-Control-Allow-Headers corretos, além do Access-Control-Allow-Origin, ou o navegador nunca chega a enviar o PUT/DELETE de verdade. Uma causa comum de "meu POST simples funciona mas meu PUT não" é justamente o servidor responder corretamente ao GET/POST simples mas não ter uma rota OPTIONS configurada para o preflight.

Exemplos práticos

PUT em API REST

Entrada: PUT /items/1, Content-Type: application/json
Saída esperada: OPTIONS enviado antes, checando Allow-Methods

O servidor precisa responder ao preflight, não só ao PUT.

GET simples

Entrada: GET /items/1
Saída esperada: Sem preflight, requisição direta

GET sem headers extras é sempre "simples".

FAQ da ferramenta completa

Por que a requisição de teste falhou com "Failed to fetch"?

Esse é justamente o sintoma de um bloqueio de CORS: o navegador rejeita a promise do fetch() antes de entregar qualquer dado ao JavaScript, sem detalhar o motivo. O problema é que essa mesma mensagem genérica também aparece em falhas de DNS, TLS ou conectividade, então o navegador não distingue as duas coisas para o script que fez a chamada.

Por que não consigo ver o header Access-Control-Allow-Origin na resposta?

O que significa "a chamada foi permitida" nesta ferramenta?

Esta ferramenta testa se qualquer site consegue chamar essa API, ou só este site?

O que é o preflight OPTIONS?

Por que enviar credenciais (cookies) muda o resultado?

Testar aqui é o mesmo que testar no código real da minha aplicação?

CORS é uma proteção do servidor ou do navegador?

Perguntas frequentes

Por que meu GET funciona mas meu PUT dá erro de CORS?

Porque o GET provavelmente é uma requisição "simples" (sem preflight), enquanto o PUT dispara um OPTIONS que o servidor pode não estar tratando corretamente, respondendo Access-Control-Allow-Methods sem incluir PUT, por exemplo.

Content-Type: text/plain com JSON dentro evita o preflight?

Tecnicamente sim, text/plain está na lista de tipos "simples", mas isso só desloca o problema: o servidor teria que confiar cegamente que o corpo é JSON válido sem a checagem de preflight, o que a maioria das APIs evita por segurança.

O preflight acontece a cada requisição?

Não necessariamente. O navegador pode cachear o resultado do preflight pelo tempo definido em Access-Control-Max-Age, evitando repetir o OPTIONS a cada chamada dentro desse período.

Próximos passos

Continuar na ferramenta

Abrir ferramenta completa

preflight OPTIONS para PUT e JSON

Preflight CORS em requisições PUT/DELETE com JSON

Um simples PUT para atualizar um recurso, o padrão mais comum em qualquer API REST, sai da lista de "requisições simples" do CORS e obriga o navegador a mandar um OPTIONS de verificação antes.

Por que uma API REST "normal" quase sempre preflighta

O CORS define uma lista curta de "requisições simples": método GET, HEAD ou POST, sem headers além de um pequeno conjunto padrão, e com Content-Type limitado a application/x-www-form-urlencoded, multipart/form-data ou text/plain. Qualquer coisa fora dessa lista, um método PUT, PATCH ou DELETE, ou um POST com Content-Type: application/json (o formato de corpo mais comum em APIs REST modernas), obriga o navegador a enviar um OPTIONS de verificação antes da requisição de verdade.

Isso significa que praticamente toda API REST séria que aceita JSON dispara preflight em requisições de escrita, e o servidor precisa responder a esse OPTIONS com os headers Access-Control-Allow-Methods e Access-Control-Allow-Headers corretos, além do Access-Control-Allow-Origin, ou o navegador nunca chega a enviar o PUT/DELETE de verdade. Uma causa comum de "meu POST simples funciona mas meu PUT não" é justamente o servidor responder corretamente ao GET/POST simples mas não ter uma rota OPTIONS configurada para o preflight.

Exemplos práticos

PUT em API REST

Entrada: PUT /items/1, Content-Type: application/json
Saída esperada: OPTIONS enviado antes, checando Allow-Methods

O servidor precisa responder ao preflight, não só ao PUT.

GET simples

Entrada: GET /items/1
Saída esperada: Sem preflight, requisição direta

GET sem headers extras é sempre "simples".

FAQ da ferramenta completa

Por que a requisição de teste falhou com "Failed to fetch"?

Por que não consigo ver o header Access-Control-Allow-Origin na resposta?

O que significa "a chamada foi permitida" nesta ferramenta?

Esta ferramenta testa se qualquer site consegue chamar essa API, ou só este site?

O que é o preflight OPTIONS?

Por que enviar credenciais (cookies) muda o resultado?

Testar aqui é o mesmo que testar no código real da minha aplicação?

CORS é uma proteção do servidor ou do navegador?

Perguntas frequentes

Por que meu GET funciona mas meu PUT dá erro de CORS?

Content-Type: text/plain com JSON dentro evita o preflight?

O preflight acontece a cada requisição?

Não necessariamente. O navegador pode cachear o resultado do preflight pelo tempo definido em Access-Control-Max-Age, evitando repetir o OPTIONS a cada chamada dentro desse período.