Intervalle de temps entre deux demandes CORS utilisant jquery ajax

Je fais une demande CORS à un service Web utilisant jQuery $.ajax . Conformément à la norme, il existe une demande avant le vol, puis la demande POST réelle.

Ce que j’ai remarqué, c’est qu’il y a deux demandes à chaque fois que j’essaie de passer un appel de service Web (une demande POST avant le vol et une demande POST réelle) uniquement s’il existe un intervalle de temps entre les deux demandes.

Si je continue à appeler le service Web successivement, sans aucun décalage dans le temps (par exemple, moins d’une seconde entre deux demandes), le contrôle préalable est manquant.

Comment puis-je éviter cette demande de pré-vol à chaque fois?

Quel est cet intervalle de temps?

Est-ce quelque chose de spécifique au navigateur Chrome?

Il existe des différences entre les navigateurs dans la manière dont ils implémentent la mise en cache avant le vol. Malheureusement, la spécification W3C n’explique pas à elle seule les nuances que vous avez observées dans la mise en cache avant le vol.

Pour les autres lecteurs de cette question, j’aimerais expliquer que, lorsque le PO déclare une demande de contrôle préalable au vol, il se réfère à la demande OPTIONS qui précède une demande POST origine croisée. La requête OPTIONS est utilisée pour interroger une API et déterminer les méthodes HTTP autorisées pour les requêtes croisées. Généralement, vous vous attendez à voir ce type de réponse à une demande OPTIONS :

 Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Content-Type, X-Requested-With Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT

Puisque vous travaillez avec Google Chrome , je vous renvoie à la section applicable du code source du Webkit :

https://github.com/WebKit/webkit/blob/master/Source/WebCore/loader/CrossOriginPreflightResultCache.cpp

La temporisation de la mémoire cache avant vol par défaut est de 5 secondes:

 static const auto defaultPreflightCacheTimeout = std::chrono::seconds(5);

La valeur maximale est de 5 minutes:

 static const auto maxPreflightCacheTimeout = std::chrono::seconds(600);

Le serveur peut spécifier une valeur de délai d’expiration pour les demandes préalables au vol à l’aide du champ Access-Control-Max-Age de l’en-tête de la réponse. Toutefois, le navigateur Webkit impose un délai d’ expiration maximal de 5 minutes.

Pour répondre à vos questions:

Comment puis-je éviter cette demande de pré-vol à chaque fois?

Vous devez définir Access-Control-Max-Age sur 600 dans l’en-tête de votre réponse d’API à la demande OPTIONS .

Quel est cet intervalle de temps?

Pour les navigateurs Webkit (Google Chrome, par exemple), le délai d’expiration par défaut est de 5 secondes . C’est pourquoi vous voyez la demande de pré-vol avant chaque demande POST, mais si vous soumettez rapidement des demandes POST, vous ne verrez pas de demandes supplémentaires de pré-vol.

Est-ce quelque chose de spécifique au navigateur Chrome?

Oui , il existe des différences entre les navigateurs quant à la mise en œuvre de la mise en cache avant le vol. La spécification W3C ne spécifie pas tout ce qui est nécessaire pour créer une fonctionnalité de mise en cache avant le vol dans un navigateur Web.

Le navigateur ne fera pas de demande de contrôle en amont si les deux situations suivantes sont vraies:

Pour la méthode de requête, il existe soit une correspondance de méthode, soit une méthode simple et l’indicateur de contrôle en amont forcé est désactivé.
Pour chaque en-tête d’en-tête de demande d’auteur, il existe soit une correspondance de cache d’en-tête pour le nom du champ, soit un en-tête simple.

Cette référence indique les responsabilités de l’utilisateur (navigateur) avec CORS: http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0

Sinon, vous ne devriez pas vous en inquiéter. La mise en œuvre du navigateur fera le bon choix.