Une brève discussion sur les demandes de contrôle en amont

Contexte

Je ne sais pas si vous avez remarqué que parfois, lorsque nous appelons l'interface en arrière-plan, nous le demandons deux fois. Comme indiqué ci-dessous

En fait, la première fois envoyée est la demande de contrôle en amont (demande de contrôle en amont), donc cet article expliquera pourquoi et quand envoyer la demande de contrôle en amont. Une demande de contrôle en amont sera envoyée, et que fait-elle dans la demande de contrôle en amont

1 Pourquoi une demande de contrôle en amont devrait-elle être envoyée ?

Nous connaissons tous la politique de même origine du navigateur, qui. est pour des raisons de sécurité. Le serveur limitera les requêtes HTTP inter-domaines initiées à partir de scripts, tels que XMLHttpRequest et Fetch, qui suivent la politique de même origine.
Il existe généralement deux manières pour les navigateurs de restreindre les requêtes inter-domaines :
1 Le navigateur restreint le lancement de requêtes inter-domaines
2 Les requêtes inter-domaines peuvent être lancées normalement, mais les résultats renvoyés. sont interceptés par le navigateur

Généralement, les navigateurs limitent les requêtes inter-domaines de la deuxième manière, ce qui signifie que la requête a atteint le serveur et peut avoir opéré sur les données de la base de données, mais que le résultat renvoyé a été intercepté par le navigateur, alors nous Le résultat du retour ne peut pas être obtenu. Il s'agit d'une requête ayant échoué, mais cela peut avoir un impact sur les données de la base de données.

Afin d'éviter que cela ne se produise, la spécification exige que pour cette méthode de requête HTTP pouvant avoir des effets secondaires sur les données du serveur, le navigateur doit d'abord utiliser la méthode OPTIONS pour lancer une requête de contrôle en amont afin de savoir si le serveur Autoriser la requête inter-domaine : si autorisé, envoyer la vraie requête avec les données sinon, empêcher l'envoi de la vraie requête avec les données ;

2. Quand envoyer une demande de contrôle en amont

Les requêtes HTTP incluent : les demandes simples et les demandes nécessitant un contrôle en amont

1 Requêtes simples

Requêtes simples CORS en amont. la demande ne sera pas déclenchée, "Jian appartient à
Le terme « requête unique » n'appartient pas à la spécification Fetch (où CORS est défini
Une requête peut être considérée comme une « requête simple » si toutes les conditions suivantes sont remplies :
). - Utilisez l'une des méthodes suivantes :
- GET
- HEAD
- POST
- Content-Type : (Ce n'est que lorsque la valeur Content-Type de la méthode POST est égale à l'un des éléments suivants qu'elle est considérée comme une exigence simple)
                                                                                    -                                                                                      - - text/plain
multipart/form-data
application/x-www-form-urlencodedRemarque :

WebKit Nightly et Safari Technology Preview sont les champs d'en-tête Accept

, Accept-Language

et Content-Language . Les valeurs ajoutent des contraintes supplémentaires. Si les valeurs de ces champs d'en-tête sont "non standards", WebKit/Safari ne traitera pas ces requêtes comme de "simples requêtes". WebKit/Safari ne répertorie pas les valeurs « non standard » dans la documentation, mais nous pouvons trouver une discussion ici : Exiger un contrôle en amont pour les en-têtes de requête non standard sécurisés par CORS Accept, Accept-Language et Content-Language, Autorisez les virgules dans les en-têtes de requête Accept, Accept-Language et Content-Language pour les requêtes CORS simples, et passez à un modèle de liste noire pour les en-têtes Accept restreints dans les requêtes CORS simples. Les autres navigateurs ne prennent pas en charge ces restrictions supplémentaires car elles ne font pas partie de la spécification.

2. Demandes nécessitant un contrôle en amont

"Demandes nécessitant un contrôle en amont" nécessite que vous deviez d'abord utiliser la méthode

pour lancer une demande de contrôle en amont vers la zone de service afin de savoir si le serveur Autorisez la demande réelle. L'utilisation de « requêtes de contrôle en amont » peut éviter que les requêtes inter-domaines n'aient des effets inattendus sur les données utilisateur sur le serveur.

Une demande de contrôle en amont doit être envoyée en premier lorsque la demande remplit l'une des conditions suivantes :

- Vous avez utilisé l'une des méthodes HTTP suivantes : OPTIONS -

-

- PUT
- DELETE
- CONNECT
- OPTIONS
- Définir artificiellement des champs d'en-tête autres que l'ensemble de champs d'en-tête sécurisé CORS. L'ensemble est : TRACE -
PATCH -

- Accept
- Accept-Language
- Content-Language
- Content-Type
- DPR
- Downlink
- Save-Data
- La valeur de Viewport-Width n'est pas une des suivantes :
- - Width
- - Content-Type
- - application/x-www-form-urlencoded

Ce qui suit est une requête HTTP qui doit effectuer une requête de contrôle en amont :

var invocation = new XMLHttpRequest();
var url = ' 
var body = &#39;<?xml version="1.0"?><person><name>Arun</name></person>&#39;;function callOtherDomain(){
  if(invocation)
    {
      invocation.open(&#39;POST&#39;, url, true);
      invocation.setRequestHeader(&#39;X-PRODUCT&#39;, &#39;H5&#39;);
      invocation.setRequestHeader(&#39;Content-Type&#39;, &#39;application/xml&#39;);
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}
......

Le code ci-dessus utilise une requête POST pour envoyer un document XML, qui contient un champ d'en-tête personnalisé (X-PRODUCT : H5). De plus, le Content-Type de cette demande est application/xml. Par conséquent, la demande doit d’abord lancer une « demande de contrôle en amont ».

1. OPTIONS /resources/post-here/ 
2. HTTP/1.13. Host: bar.other4. User-Agent: Mozilla/5.0 (Macintosh; U; 5.Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre6. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.87. Accept-Language: en-us,en;q=0.58. Accept-Encoding: gzip,deflate9. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.710. Connection: keep-alive11. Origin: http://foo.example12. Access-Control-Request-Method: POST13. Access-Control-Request-Headers: X-PINGOTHER, Content-Type14. HTTP/1.1 200 OK15. Date: Mon, 01 Dec 2008 01:15:39 GMT16. Server: Apache/2.0.61 (Unix)17. Access-Control-Allow-Origin: http://foo.example18. Access-Control-Allow-Methods: POST, GET, OPTIONS19. Access-Control-Allow-Headers: X-PINGOTHER, Content-Type20. Access-Control-Max-Age: 8640021. Vary: Accept-Encoding, Origin22. Content-Encoding: gzip23. Content-Length: 024. Keep-Alive: timeout=2, max=10025. Connection: Keep-Alive26. Content-Type: text/plain

Comme vous pouvez le voir dans le message ci-dessus, les lignes 1 à 12 envoient une demande de contrôle en amont en utilisant la méthode OPTIONS. OPTIONS est une méthode définie dans le protocole HTTP/1.1 pour obtenir plus d'informations du serveur. Cette méthode n'a aucun impact sur les ressources du serveur. La requête comporte simultanément les deux champs d'en-tête suivants :

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PRODUCT

Le champ d'en-tête Access-Control-Request-Method indique au serveur que la requête réelle utilisera la méthode POST. Le champ d'en-tête Access-Control-Request-Headers indique au serveur que la requête réelle comportera deux champs d'en-tête de requête personnalisés : X-PINGOTHER et Content-Type. Le serveur décide en fonction de cela si la demande réelle est autorisée.

Les lignes 14 à 26 sont des réponses aux demandes de contrôle en amont, indiquant que le serveur s'en tiendra aux demandes réelles ultérieures. Focus sur les lignes 17~20 :

Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400

Le champ d'en-tête Access-Control-Allow-Methods indique que le serveur permet au client d'initier des requêtes en utilisant les méthodes POST, GET et OPTIONS. Le champ d'en-tête

Access-Control-Allow-Headers indique que le serveur autorise le transport des champs X-PINGOTHER et Content-Type dans la requête. Comme Access-Control-Allow-Methods, la valeur de Access-Control-Allow-Headers est une liste séparée par des virgules.

Enfin, le champ d'en-tête

Access-Control-Max-Age indique que la réponse est valide pendant 86400 secondes, soit 24 heures. Pendant la période de validité, le navigateur n’a pas besoin de lancer à nouveau une demande de contrôle en amont pour la même demande. Veuillez noter que le navigateur lui-même maintient une durée de validité maximale. Si la valeur de ce champ d'en-tête dépasse la durée de validité maximale, il ne prendra pas effet.

Une fois la demande de contrôle en amont terminée, envoyez la demande réelle :

POST /resources/post-here/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-aliveX-PINGOTHER: pingpongContent-Type: text/xml; charset=UTF-8Referer: http://foo.example/examples/preflightInvocation.htmlContent-Length: 55Origin: http://foo.examplePragma: no-cacheCache-Control: no-cache<?xml version="1.0"?><person><name>Arun</name></person>HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain
[Some GZIP&#39;d payload]

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!