Pourquoi envoie-t-on une demande D'OPTIONS et puis-je la désactiver?

s'il vous Plaît consulter cette réponse sur le besoin réel de pré-flighted demande OPTIONS: de la SCRO - Quelle est la motivation derrière l'introduction du contrôle en amont des demandes?

pour désactiver la requête OPTIONS, les conditions ci-dessous doivent être remplies pour la requête ajax:

1. Demande de ne pas définir des en-têtes HTTP personnalisés comme "application/xml" ou "application/json" etc
2. la méthode request doit être une de GET, De la TÊTE ou par la POSTE. Si le POST, un type de contenu doit être l'un des application/x-www-form-urlencoded , multipart/form-data , ou text/plain

référence: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

ont traversé cette question, ci-dessous est ma conclusion à cette question et ma solution.

selon la CORS strategy (fortement recommandé de lire à ce sujet), vous ne pouvez pas juste forcer le navigateur à cesser d'envoyer la demande D'OPTION s'il pense qu'il a besoin.

il y a deux façons de travailler

• 1. assurez-vous que votre demande est une " simple demande"
• 2. Set Access-Control-Max-Age pour l'OPTION "demande de 1519140920"

Simple requête

une simple demande trans-site est une demande qui remplit toutes les conditions suivantes:

les seules méthodes autorisées sont: - OBTENIR - TÊTE - POST

à L'exclusion des en-têtes configurés automatiquement par l'agent utilisateur (par exemple connexion, User-Agent, etc.), les seuls en-têtes qui peuvent être réglés manuellement sont: - Accepter - Accept-Language - Contenu-Langue - Type De Contenu

les seules valeurs autorisées pour l'en-tête Content-Type sont: - application / x-www-form-urlencoded - multipart / form-data - text /plain

une simple demande ne donnera pas lieu à une demande d'OPTION pré-vol.

définit un cache pour le contrôle D'OPTION

vous pouvez définir un Access-Control-Max-Age pour l'OPTION de demande, de sorte qu'il ne vérifiera pas la permission de nouveau jusqu'à ce qu'il est expiré.

contrôle D'accès-max-Age donne la valeur en secondes pour combien de temps la réponse à la demande pré-vol peut être mise en cache sans envoyer une autre demande pré-vol.

Oui il est possible d'éviter les requêtes d'options. La demande d'Options est une demande pré-vol lorsque vous envoyez (post) des données à un autre domaine. C'est un problème de sécurité du navigateur. Mais nous pouvons utiliser une autre technologie: la couche de transport iframe. Je vous recommande fortement d'oublier toute configuration de CORS et d'utiliser la solution readymade et il fonctionnera n'importe où.

Regardez ici: https://github.com/jpillora/xdomain

et de travail exemple: http://jpillora.com/xdomain /

bonne journée!

lorsque la console de débogage est ouverte et que l'option Disable Cache est activée, les requêtes avant vol seront toujours envoyées (c'est-à-dire avant chaque requête). si vous ne désactivez pas le cache, une requête pré-vol ne sera envoyée qu'une seule fois (par serveur)

comme mentionné dans les billets précédents déjà, OPTIONS requêtes sont là pour une raison. Si vous avez un problème avec les temps de réponse élevés de votre serveur (par exemple connexion à l'étranger), vous pouvez également avoir votre cache de navigateur les requêtes pré-Lig niques.

faites répondre votre serveur avec l'en-tête Access-Control-Max-Age et pour les requêtes qui vont au même endpoint, la requête preflight aura été mise en cache et ne se produira plus.

pour un développeur qui comprend la raison pour laquelle il existe, mais qui a besoin d'accéder à une API qui ne gère pas les appels D'OPTIONS sans autorisation, j'ai besoin d'une réponse temporaire afin de pouvoir développer localement jusqu'à ce que le propriétaire de L'API ajoute le support approprié de L'API CORS ou que j'obtienne une API proxy qui démarre.

j'ai trouvé que vous pouvez désactiver CORS en Safari et Chrome sur un Mac.

Désactiver la même origine dans Chrome

Chrome: Quit Chrome, ouvrir un terminal et coller cette commande: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir

Safari: la Désactivation de l'origine de la politique dans Safari

si vous voulez désactiver la Politique de même origine sur Safari (j'ai 9.1.1), alors vous n'avez qu'à activer le menu developer, et sélectionner" Désactiver les Restrictions D'origine croisée " dans le menu develop.

j'ai résolu ce problème comme.

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();
}

il est seulement pour le développement. Avec ceci j'attends 9ms et 500ms et pas 8s et 500ms. Je peux le faire parce que production js app sera sur la même machine que la production donc il n'y aura pas de OPTIONS mais le développement est mon local.

vous ne pouvez pas mais vous pouvez éviter les CORS en utilisant JSONP.

après avoir passé une journée et demie à essayer de résoudre un problème similaire, j'ai trouvé qu'il avait à voir avec IIS .

mon projet D'API Web a été configuré comme suit:

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

Je n'avais pas les options de configuration sur le web.config > système.noeud webServer comme j'ai vu dans tant de messages

pas de code spécifique CORS dans le global.asax ou dans le contrôleur en tant que décorateur

, le problème était Le application des paramètres du pool .

le managed pipeline mode a été mis à la classique ( l'a changé à Intégré ) et le identité a été mis au service de réseau ( l'a changé à ApplicationPoolIdentity )

changer ces paramètres (et rafraîchir l'application la piscine), il fixe pour moi.

ce qui a fonctionné pour moi était d'importer "github.com/gorilla/handlers "et puis l'utiliser de cette façon:

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)))

dès que j'exécutais une requête Ajax POST et y attachais des données JSON, Chrome ajoutait toujours l'en-tête Content-Type qui n'était pas dans ma précédente configuration AllowedHeaders.

je pense, vous envoyez une demande à cross domain .

Pour cross-domain "151930920 les demandes", le réglage du type de contenu à autre chose que application / x-www-form-urlencoded , multipart/form-data , ou text / plain va déclencher le navigateur pour envoyer un Preflight OPTIONS demande au serveur.

$.ajax({
    url: "http://crossdomainurl",
    type: "POST",
    contentType: 'text/plain'
});