Por que uma solicitação OPTIONS é enviada e posso desativá-la?

Estou construindo uma API da web. Descobri que sempre que uso o Chrome para POST, GET para minha API, sempre há uma solicitação de OPÇÕES enviada antes da solicitação real, o que é bastante irritante. Atualmente, eu recebo o servidor para ignorar quaisquer solicitações de OPÇÕES. Agora, minhas perguntas são: o que é bom para enviar uma solicitação OPTIONS para dobrar a carga do servidor? Existe alguma maneira de impedir completamente o navegador de enviar solicitações OPTIONS?

editar 2018-09-13 : adicionadas algumas precisões sobre essa solicitação antes do voo e como evitá-la no final desta resposta.

OPTIONSsolicitações são o que chamamos de pre-flightsolicitações Cross-origin resource sharing (CORS).

Eles são necessários quando você faz solicitações de diferentes origens em situações específicas.

Essa solicitação de pré-vôo é feita por alguns navegadores como uma medida de segurança para garantir que a solicitação que está sendo feita seja confiável pelo servidor. Significando que o servidor entende que o método, a origem e os cabeçalhos enviados na solicitação são seguros para agir.

Seu servidor não deve ignorar, mas manipular essas solicitações sempre que você estiver tentando fazer solicitações de origem cruzada.

Um bom recurso pode ser encontrado aqui http://enable-cors.org/

Uma maneira de lidar com eles para ficar confortável é garantir que, para qualquer caminho com o OPTIONSmétodo, o servidor envie uma resposta com esse cabeçalho

Access-Control-Allow-Origin: *

Isso informará ao navegador que o servidor está disposto a responder a solicitações de qualquer origem.

Para obter mais informações sobre como adicionar suporte CORS ao seu servidor, consulte o fluxograma a seguir

http://www.html5rocks.com/static/images/cors_server_flowchart.png

editar 2018-09-13

A OPTIONSsolicitação CORS é acionada apenas em alguns casos, conforme explicado nos documentos MDN :

Algumas solicitações não acionam um preflight do CORS. Essas são chamadas de "solicitações simples" neste artigo, embora a especificação Fetch (que define o CORS) não use esse termo. Uma solicitação que não aciona uma verificação prévia do CORS - a chamada "solicitação simples" - é aquela que atende a todas as seguintes condições:

Os únicos métodos permitidos são:

• PEGUE
• CABEÇA
• POSTAR

Além dos cabeçalhos definidos automaticamente pelo agente do usuário (por exemplo, Connection, User-Agent ou qualquer outro cabeçalho com nomes definidos na especificação Buscar como um "nome de cabeçalho proibido"), os únicos cabeçalhos que podem ser definidos manualmente são aqueles que a especificação Fetch define como sendo um "cabeçalho de solicitação listado na lista de segurança do CORS", que são:

• Aceitar
• Accept-Language
• Idioma do Conteúdo
• Tipo de conteúdo (mas observe os requisitos adicionais abaixo)
• DPR
• Downlink
• Guardar dados
• Largura da janela de visualização
• Largura

Os únicos valores permitidos para o cabeçalho Content-Type são:

• application / x-www-form-urlencoded
• multipart / form-data
• texto / simples

Nenhum ouvinte de evento é registrado em nenhum objeto XMLHttpRequestUpload usado na solicitação; estes são acessados ​​usando a propriedade XMLHttpRequest.upload.

Nenhum objeto ReadableStream é usado na solicitação.

Passamos por esse problema, abaixo está minha conclusão sobre esse problema e minha solução.

De acordo com a estratégia do CORS (é altamente recomendável que você leia sobre isso) Você não pode simplesmente forçar o navegador a parar de enviar a solicitação OPTIONS, se achar necessário.

Existem duas maneiras de contornar isso:

1. Verifique se sua solicitação é uma "solicitação simples"
2. Definido Access-Control-Max-Agepara a solicitação OPTIONS

Pedido simples

Uma solicitação simples entre sites é aquela que atende a todas as seguintes condições:

Os únicos métodos permitidos são:

• PEGUE
• CABEÇA
• POSTAR

Além dos cabeçalhos definidos automaticamente pelo agente do usuário (por exemplo, Conexão, User-Agent, etc.), os únicos cabeçalhos que podem ser configurados manualmente são:

• Aceitar
• Accept-Language
• Idioma do Conteúdo
• Tipo de conteúdo

Os únicos valores permitidos para o cabeçalho Content-Type são:

• application / x-www-form-urlencoded
• multipart / form-data
• texto / simples

Uma solicitação simples não causará uma solicitação de OPÇÕES antes do voo.

Defina um cache para a verificação OPTIONS

Você pode definir um Access-Control-Max-Agepara a solicitação OPTIONS, para que ela não verifique a permissão novamente até expirar.

O Access-Control-Max-Age fornece o valor em segundos por quanto tempo a resposta à solicitação de comprovação pode ser armazenada em cache sem enviar outra solicitação de comprovação.

Limitação observada

• Para cromo, os segundos máximos para Access-Control-Max-Ageé 600que é de 10 minutos, de acordo com cromo código fonte
• Access-Control-Max-Agefunciona apenas para um recurso toda vez, por exemplo, GETsolicitações com o mesmo caminho de URL, mas consultas diferentes serão tratadas como recursos diferentes. Portanto, a solicitação para o segundo recurso ainda acionará uma solicitação de comprovação.

Consulte esta resposta sobre a necessidade real de solicitação de OPÇÕES pré-veiculada: CORS - Qual é a motivação por trás da introdução de solicitações de pré-voo?

Para desativar a solicitação OPTIONS, as condições abaixo devem ser atendidas para a solicitação ajax:

1. A solicitação não define cabeçalhos HTTP personalizados como 'application / xml' ou 'application / json' etc.
2. O método de solicitação deve ser um dos métodos GET, HEAD ou POST. Se POST, tipo de conteúdo deve ser uma das application/x-www-form-urlencoded, multipart/form-dataoutext/plain

Referência: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Quando você tiver o console de depuração aberto e a Disable Cacheopção ativada, as solicitações de comprovação sempre serão enviadas (ou seja, antes de cada solicitação). se você não desabilitar o cache, uma solicitação pré-vôo será enviada apenas uma vez (por servidor)

Sim, é possível evitar a solicitação de opções. A solicitação de opções é uma solicitação de comprovação quando você envia (publica) quaisquer dados para outro domínio. É um problema de segurança do navegador. Mas podemos usar outra tecnologia: camada de transporte iframe. Eu recomendo fortemente que você esqueça qualquer configuração do CORS e use a solução readymade e ela funcionará em qualquer lugar.

Dê uma olhada aqui: https://github.com/jpillora/xdomain

E exemplo de trabalho: http://jpillora.com/xdomain/

Para um desenvolvedor que entende o motivo da existência, mas precisa acessar uma API que não lida com chamadas OPTIONS sem autenticação, preciso de uma resposta temporária para que eu possa desenvolver localmente até que o proprietário da API adicione suporte SPA CORS adequado ou obtenha uma API proxy funcionando.

Descobri que você pode desativar o CORS no Safari e Chrome em um Mac.

Desativar a mesma política de origem no Chrome

Chrome: saia do Chrome, abra um terminal e cole este comando: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir

Safari: desativando a política de mesma origem no Safari

Se você deseja desativar a política de mesma origem no Safari (eu tenho a versão 9.1.1), você só precisa ativar o menu do desenvolvedor e selecionar "Desativar restrições de origem cruzada" no menu de desenvolvimento.

Como mencionado nas postagens anteriores, as OPTIONSsolicitações existem por um motivo. Se você tiver um problema com grandes tempos de resposta do servidor (por exemplo, conexão com o exterior), também poderá fazer com que o navegador armazene em cache as solicitações de comprovação.

Faça com que o servidor responda com o Access-Control-Max-Agecabeçalho e, para solicitações que vão para o mesmo terminal, a solicitação de comprovação será armazenada em cache e não ocorrerá mais.

Eu resolvi esse problema como.

if($_SERVER['REQUEST_METHOD'] == 'OPTIONS' && ENV == 'devel') {
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Headers: X-Requested-With');
    header("HTTP/1.1 200 OK");
    die();
}

É apenas para o desenvolvimento. Com isso eu estou esperando 9ms e 500ms e não 8s e 500ms. Eu posso fazer isso porque o aplicativo JS de produção estará na mesma máquina que a produção, portanto não haverá, OPTIONSmas o desenvolvimento é o meu local.

Você não pode, mas pode evitar o CORS usando JSONP.

Depois de passar um dia e meio tentando resolver um problema semelhante, descobri que tinha a ver com o IIS .

Meu projeto de API da Web foi configurado da seguinte maneira:

// WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
    var cors = new EnableCorsAttribute("*", "*", "*");
    config.EnableCors(cors);
    //...
}

Eu não tinha opções de configuração específicas do CORS no nó web.config> system.webServer, como já vi em tantas postagens

Nenhum código específico do CORS no global.asax ou no controlador como decorador

O problema foram as configurações do pool de aplicativos .

O modo de pipeline gerenciado foi definido como clássico ( alterado para integrado ) e a Identidade foi definida como Serviço de Rede ( alterada para ApplicationPoolIdentity )

Alterar essas configurações (e atualizar o pool de aplicativos) corrigiu isso para mim.

O que funcionou para mim foi importar "github.com/gorilla/handlers" e depois usá-lo desta maneira:

router := mux.NewRouter()
router.HandleFunc("/config", getConfig).Methods("GET")
router.HandleFunc("/config/emcServer", createEmcServers).Methods("POST")

headersOk := handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type"})
originsOk := handlers.AllowedOrigins([]string{"*"})
methodsOk := handlers.AllowedMethods([]string{"GET", "HEAD", "POST", "PUT", "OPTIONS"})

log.Fatal(http.ListenAndServe(":" + webServicePort, handlers.CORS(originsOk, headersOk, methodsOk)(router)))

Assim que eu executava uma solicitação Ajax POST e anexava dados JSON a ela, o Chrome sempre adicionava o cabeçalho Content-Type que não estava na minha configuração anterior do AllowedHeaders.

Uma solução que eu usei no passado - digamos que seu site esteja em mydomain.com e você precise fazer uma solicitação de ajax para foreigndomain.com

Configure uma reescrita do IIS do seu domínio para o domínio externo - por exemplo

<rewrite>
  <rules>
    <rule name="ForeignRewrite" stopProcessing="true">
        <match url="^api/v1/(.*)$" />
        <action type="Rewrite" url="https://foreigndomain.com/{R:1}" />
    </rule>
  </rules>
</rewrite>

no site mydomain.com - você pode fazer a mesma solicitação de origem e não há necessidade de opções :)

Pode ser resolvido em caso de uso de um proxy que intercepte a solicitação e grave os cabeçalhos apropriados. No caso particular do verniz, estas seriam as regras:

if (req.http.host == "CUSTOM_URL" ) {
set resp.http.Access-Control-Allow-Origin = "*";
if (req.method == "OPTIONS") {
   set resp.http.Access-Control-Max-Age = "1728000";
   set resp.http.Access-Control-Allow-Methods = "GET, POST, PUT, DELETE, PATCH, OPTIONS";
   set resp.http.Access-Control-Allow-Headers = "Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since";
   set resp.http.Content-Length = "0";
   set resp.http.Content-Type = "text/plain charset=UTF-8";
   set resp.status = 204;
}

}

Talvez haja uma solução (mas eu não a testei): você poderia usar o CSP (Política de segurança de conteúdo) para ativar seu domínio remoto e os navegadores talvez ignorem a verificação de solicitação do CORS OPTIONS.

Se encontrar algum tempo, testarei isso e atualizarei este post!

CSP: https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Content-Security-Policy

Especificação do CSP: https://www.w3.org/TR/CSP/