Während des Debuggens eines CORS-Problems habe ich folgendes Verhalten festgestellt. Chrome stellt die folgende Preflight-Anforderung OPTIONS (von Chrome selbst in CURL umgeschrieben):

curl -v 'https://www.example.com/api/v1/users' -X OPTIONS -H 'Access-Control-Request-Method: POST' -H 'Origin: http://example.com' -H 'Accept-Encoding: gzip,deflate,sdch' -H 'Accept-Language: es-ES,es;q=0.8,en;q=0.6' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36' -H 'Accept: */*' -H 'Referer: http://example.com/users/new' -H 'Connection: keep-alive' -H 'Access-Control-Request-Headers: accept, x-api-key, content-type'

Die Antwort des Servers auf diese Anforderung lautet wie folgt:

< HTTP/1.1 403 Forbidden
< Date: Thu, 21 Jul 2016 14:16:56 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: SAMEORIGIN
< Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
< Content-Length: 20
< Keep-Alive: timeout=5, max=100
< Connection: Keep-Alive

Der Hauptteil der Antwort "Ungültige CORS-Anforderung". Wenn ich die Anfrage wiederhole und den Header 'Access-Control-Request-Method' (und nur diesen Header) entferne, sind die OPTIONS-Anfragen mit der folgenden Antwort erfolgreich:

< HTTP/1.1 200 OK
< Date: Thu, 21 Jul 2016 14:21:27 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: SAMEORIGIN 
< Access-Control-Allow-Headers: origin, content-type, accept, x-requested-with, x-api-key
< Access-Control-Max-Age: 60
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
< Access-Control-Allow-Origin: *
< Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
< Content-Length: 0
< Keep-Alive: timeout=5, max=100
< Connection: Keep-Alive

Der anstößige Header ist jedoch einCORS spec standard header so sollte es nicht verhindern, dass die Anfrage erfolgreich ist, oder? Warum verursacht dieser Header ein solches Verhalten?

Und wie kann ich die von meinem Server gesendeten Zugriffssteuerungsheader optimieren, damit die Anforderung in Chrome funktioniert?

Übrigens verwende ich Chrome 36.0 und der Server verwendet Spring Boot, wobei die CORS-Header von Spring verwaltet werden.

Wenn die Anfrage von Firefox (v47.0) gestellt wird, ist das Verhalten anders, aber mit einem analogen Ergebnis. Firefox sendet nicht einmal die Preflight-Anfrage, sondern sendet direkt die POST-Anfrage, die als Antwort eine 403 Forbidden erhält. Wenn ich die Anforderung jedoch mit der Option "Als cURL kopieren" kopiere und sie in einem Terminalfenster wiederhole, ist sie erfolgreich und sendet die richtigen CORS-Header in der Antwort.

Irgendeine Idee

Aktualisiere: Firefox sendet die Preflight-OPTIONEN-Anforderung (wie vom Live-HTTP-Header-Plugin angezeigt), Firebug maskiert sie jedoch, sodass das Verhalten in beiden Browsern genau gleich ist. In beiden Browsern ist der Header "Zugriffskontrollanforderungsmethode" der Unterschied, durch den die Anforderung fehlschlägt.