Domänenübergreifende gemeinsame Nutzung von CORS-Ressourcen, detaillierte Erklärung_Javascript-Kenntnisse

Es ermöglicht dem Browser XMLHttpRequest Anfragen an Cross-Origin-Server zu stellen, wodurch die Einschränkung überwunden wird, dass AJAX nur von demselben Ursprung aus verwendet werden kann.

In diesem Artikel wird der interne Mechanismus von CORS ausführlich vorgestellt.

(Bildbeschreibung: Aufgenommen im Oasis Park in Al Ain, Vereinigte Arabische Emirate)

1. Einleitung

CORS erfordert sowohl Browser- als auch Serverunterstützung. Derzeit unterstützen alle Browser diese Funktion und der IE-Browser darf nicht niedriger als IE10 sein.

Der gesamte CORS-Kommunikationsprozess wird automatisch vom Browser abgeschlossen und erfordert keine Benutzerbeteiligung. Für Entwickler gibt es keinen Unterschied zwischen CORS-Kommunikation und AJAX-Kommunikation aus derselben Quelle, und der Code ist genau derselbe. Sobald der Browser feststellt, dass die AJAX-Anfrage ursprungsübergreifend ist, fügt er automatisch einige zusätzliche Header-Informationen hinzu, und manchmal wird eine zusätzliche Anfrage gestellt, aber der Benutzer wird dies nicht spüren.

Daher ist der Server der Schlüssel zum Erreichen der CORS-Kommunikation. Solange der Server die CORS-Schnittstelle implementiert, ist eine Cross-Origin-Kommunikation möglich.

2. Zwei Arten von Anfragen

Browser unterteilen CORS-Anfragen in zwei Kategorien: einfache Anfragen und nicht ganz so einfache Anfragen.

Solange die folgenden beiden Bedingungen gleichzeitig erfüllt sind, handelt es sich um eine einfache Anfrage.

(1) Die Anforderungsmethode ist eine der folgenden drei Methoden:

HEADGETPOST

(2) HTTP-Header-Informationen überschreiten nicht die folgenden Felder:

AcceptAccept-LanguageContent-LanguageLast-Event-IDContent-Type: begrenzt auf drei Werte application/x-www-form-urlencoded, multipart/form-data, text/plain

Jede Anfrage, die nicht gleichzeitig die beiden oben genannten Bedingungen erfüllt, ist eine nicht einfache Anfrage.

Browser behandeln diese beiden Anfragen unterschiedlich.

3. Einfache Anfrage 3.1 Grundlegender Prozess

Bei einfachen Anfragen gibt der Browser CORS-Anfragen direkt aus. Konkret geht es darum, den Header-Informationen ein Origin-Feld hinzuzufügen.

Das Folgende ist ein Beispiel. Der Browser stellt fest, dass es sich bei dieser ursprungsübergreifenden AJAX-Anfrage um eine einfache Anfrage handelt, und fügt den Header-Informationen automatisch ein Origin-Feld hinzu.

GET /cors HTTP/1.1Origin: http://api.bob.comHost: api.alice.comAccept-Language: en-USConnection: keep-aliveUser-Agent: Mozilla/5.0...

In den obigen Header-Informationen wird das Feld Origin verwendet, um anzugeben, von welcher Quelle diese Anfrage stammt (Protokoll + Domänenname + Port). Der Server entscheidet anhand dieses Werts, ob er der Anfrage zustimmt.

Wenn die durch Origin angegebene Quelle nicht innerhalb des Berechtigungsbereichs liegt, gibt der Server eine normale HTTP-Antwort zurück. Wenn der Browser feststellt, dass die Header-Informationen dieser Antwort das Feld Access-Control-Allow-Origin nicht enthalten (Einzelheiten siehe unten), weiß er, dass etwas schief gelaufen ist, und gibt einen Fehler aus, der von der Rückruffunktion XMLHttpRequest von . Beachten Sie, dass dieser Fehler nicht anhand des Statuscodes identifiziert werden kann, da der Statuscode der HTTP-Antwort möglicherweise 200 lautet. onerror

Wenn der durch

angegebene Domänenname innerhalb des Berechtigungsbereichs liegt, enthält die vom Server zurückgegebene Antwort mehrere weitere Header-Informationsfelder. Origin

Access-Control-Allow-Origin: http://api.bob.comAccess-Control-Allow-Credentials: trueAccess-Control-Expose-Headers: FooBarContent-Type: text/html; charset=utf-8

Unter den oben genannten Header-Informationen gibt es drei Felder, die sich auf CORS-Anfragen beziehen und alle mit

beginnen. Access-Control-

(1) Access-Control-Allow-Origin

Dieses Feld ist erforderlich. Sein Wert ist entweder der Wert des Felds

während der Anfrage oder ein Origin, der angibt, dass Anfragen von jedem Domänennamen akzeptiert werden. *

(2) Zugangskontrolle-Zulassen-Anmeldeinformationen

Dieses Feld ist optional. Sein Wert ist ein boolescher Wert, der angibt, ob das Senden von Cookies zulässig ist. Standardmäßig sind Cookies nicht in CORS-Anfragen enthalten. Auf

setzen, was bedeutet, dass der Server explizit zulässt, dass das Cookie in die Anfrage aufgenommen und an den Server gesendet wird. Dieser Wert kann nur auf true gesetzt werden. Wenn der Server nicht möchte, dass der Browser Cookies sendet, löschen Sie einfach dieses Feld. true

(3) Access-Control-Expose-Header

Dieses Feld ist optional. Bei einer CORS-Anfrage kann die

-Methode des XMLHttpRequest-Objekts nur 6 Grundfelder abrufen: getResponseHeader(), Cache-Control, Content-Language, Content-Type, Expires, Last-Modified. Wenn Sie andere Felder erhalten möchten, müssen Sie diese in Pragma angeben. Das obige Beispiel gibt an, dass Access-Control-Expose-Headers den Wert des Felds getResponseHeader('FooBar') zurückgeben kann. FooBar

3.2 withCredentials-Attribut

Wie oben erwähnt, senden CORS-Anfragen standardmäßig keine Cookie- und HTTP-Authentifizierungsinformationen. Wenn Sie Cookies an den Server senden möchten, benötigen Sie die Zustimmung des Servers und geben das Feld

an. Access-Control-Allow-Credentials

<code>Access-Control-Allow-Credentials: true</code>

Andererseits müssen Entwickler das Attribut

in AJAX-Anfragen aktivieren. withCredentials

<code>var xhr = new XMLHttpRequest();xhr.withCredentials = true;</code>

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

<code>xhr.withCredentials = false;</code>

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

四、非简单请求4.1 预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

下面是一段浏览器的JavaScript脚本。

var url = 'http://api.alice.com/cors';var xhr = new XMLHttpRequest();xhr.open('PUT', url, true);xhr.setRequestHeader('X-Custom-Header', 'value');xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

<code>OPTIONS /cors HTTP/1.1Origin: http://api.bob.comAccess-Control-Request-Method: PUTAccess-Control-Request-Headers: X-Custom-HeaderHost: api.alice.comAccept-Language: en-USConnection: keep-aliveUser-Agent: Mozilla/5.0...</code>

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

4.2 预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://api.bob.comAccess-Control-Allow-Methods: GET, POST, PUTAccess-Control-Allow-Headers: X-Custom-HeaderContent-Type: text/html; charset=utf-8Content-Encoding: gzipContent-Length: 0Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-Type: text/plain

上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示<a href="http://api.bob.com">http://api.bob.com</a>可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。

Access-Control-Allow-Origin: *

如果浏览器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。

XMLHttpRequest cannot load http://api.alice.com.Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

服务器回应的其他CORS相关字段如下。

<code>Access-Control-Allow-Methods: GET, POST, PUTAccess-Control-Allow-Headers: X-Custom-HeaderAccess-Control-Allow-Credentials: trueAccess-Control-Max-Age: 1728000</code>

（1）Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

（2）Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

（3）Access-Control-Allow-Credentials

该字段与简单请求时的含义相同。

（4）Access-Control-Max-Age

Ce champ est facultatif et permet de préciser la durée de validité de cette demande de contrôle en amont, en secondes. Dans le résultat ci-dessus, la période de validité est de 20 jours (1 728 000 secondes), ce qui signifie que la réponse peut être mise en cache pendant 1 728 000 secondes (20 jours). Pendant cette période, il n'est pas nécessaire d'émettre une autre demande de contrôle en amont.

4.3 Demande normale et réponse du navigateur

Une fois que le serveur a réussi la requête "preflight", chaque requête CORS normale du navigateur sera la même qu'une simple requête, et il y aura un Origin champ d'informations d'en-tête. La réponse du serveur aura également un champ d'informations d'en-tête Access-Control-Allow-Origin.

Ce qui suit est la requête CORS normale du navigateur après la requête « contrôle en amont ».

PUT /cors HTTP/1.1Origin: http://api.bob.comHost: api.alice.comX-Custom-Header: valueAccept-Language: en-USConnection: keep-aliveUser-Agent: Mozilla/5.0...

Le champ Origin dans les informations d'en-tête ci-dessus est automatiquement ajouté par le navigateur.

Ce qui suit est une réponse normale du serveur.

Access-Control-Allow-Origin: http://api.bob.comContent-Type: text/html; charset=utf-8

Dans les informations d'en-tête ci-dessus, le champ Access-Control-Allow-Origin doit être inclus dans chaque réponse.

5. Comparaison avec JSONP

CORS est utilisé dans le même but que JSONP, mais est plus puissant que JSONP.

JSONP ne prend en charge que les GET requêtes, CORS prend en charge tous les types de requêtes HTTP. L'avantage de JSONP est qu'il prend en charge les anciens navigateurs et peut demander des données à des sites Web qui ne prennent pas en charge CORS.

(Fin)