Ich habe die Spezifikation für CORS-Anfragen gelesen und Ich habe das über Preflight-Anfragen herausgefunden:
Dies sind Anfragen an eine URL ungleich URL mit einer HTTP-Anfrage eine andere Methode als GET, die zuerst autorisiert werden muss, indem entweder a Preflight-Ergebnis-Cache-Eintrag oder eine Preflight-Anfrage.
Ich hatte gedacht, der Zweck von Preflight-Anfragen war es, zu prüfen, ob eine Anfrage erlaubt war, bevor sie gemacht wurde, falls der Server-Status geändert wurde.
Aber HEAD und OPTIONS ändern den Serverstatus nicht. Ich muss den Grund für die Preflight-Kontrolle missverstehen.
Was ist der Zweck (aka der Grund, Motivation oder Begründung) für einen Preflight-Check für Kopf und Optionen, aber nicht GET? Was ist das Besondere an GET?
Die primäre Absicht des Preflighting besteht darin, sicherzustellen, dass Server nicht plötzlich browserbasierte Cross-Origin-Anfragen gesendet werden, die sie niemals erhalten hätten, bevor die CORS-Spezifikation implementiert wurde.
Vor der CORS-Spezifikation war es nicht möglich, andere browserbasierte Ursprungsanforderungen als GET oder POST zu senden. Der Browser würde es einfach nicht erlauben, eine XHR-Instanz zu starten, die Methode auf PUT setzen (zum Beispiel) und sie an einen Endpunkt mit einem anderen Ursprung senden. Sie konnten auch keine GET- oder POST-Ursprungsanfragen über XHR senden, aber Sie könnten einen GET- oder POST-Ursprungsvorgang über eine Formularübermittlung oder eine übergreifende GET über ein <img> oder <script> -Tag, z Beispiel (wodurch JSONP zur einzigen Option vor CORS wurde). Sobald Browser die CORS-Spezifikation implementiert haben, hat sich dies geändert. Jetzt ist es möglich, eine Cross-Origin-Ajax-Anfrage zu senden, sofern der Server sich dafür entscheidet.
Die CORS-Spezifikation definiert "einfache" Methoden (GET und POST) zusammen mit "einfachen" Anforderungsheadern. Diese entsprechen den Typen von übergreifenden Anfragen, die Sie bereits aus der Browser-Pre-CORS-Spezifikation senden konnten. Nicht-einfache Cross-Origin-Anforderungen, wie beispielsweise PUT- oder POST / GET-Anfragen mit einem X-Header (zum Beispiel), konnten nicht von einer Browser-Pre-CORS-Spezifikation gesendet werden. Für diese Arten von Anfragen wurde das Konzept des Preflighting in die Spezifikation geschrieben, um sicherzustellen, dass Server diese Art von nicht-einfachen browserbasierten Cross-Source-Anfragen nicht erhalten, ohne sich explizit zu entscheiden. Mit anderen Worten, wenn nicht Möchten Sie diese Arten von Anfragen zulassen, müssen Sie Ihren Server überhaupt nicht ändern. Das Preflight schlägt fehl und der Browser sendet niemals die zugrunde liegende Anfrage.
Direkt auf Ihre Frage eingehen: HEAD-Anfragen führen normalerweise nicht zu einem Preflight. HEAD wird als eine einfache Anfrage-Methode gemäß der CORS-Spezifikation betrachtet. Wie Sie wissen, sind HEAD-Anfragen nur GETs ohne Antwort-Payload. Dies ist der wahrscheinlichste Grund, warum HEAD- und GET-Anfragen gleich behandelt werden, auch wenn Sie keine übergreifende HEAD-Anfrage pre-CORS vom Browser senden konnten. Wenn Ihr HEAD nicht einfache Header enthält, wird er jedoch wie GET Preflight sein.
Tags und Links cors cross-domain http-method preflight