Safari schlägt CORS-Anfrage nach 302 Redirect

Question

Ich habe ein Problem mit der Art, wie Safari CORS Anfragen behandelt. Betrachten Sie folgendes Szenario:

1. DomainA beherbergt eine Seite, die eine XHR Anfrage an DomainB macht (Herkunft Header auf DomainA)
2. DomainB liefert 302-Umleitung tun DomäneC (Ursprungs-Header auf null gesetzt wird, was zu sein scheint OK mit RFC)
3. DomäneC Rück 200 Antwort mit dem tatsächlichen Inhalt

Der in Chrome funktioniert, FF, aber es funktioniert nicht auf Safari (getestet auf Mozilla/5.0 (Macintosh, Intel Mac OS X 10_10_5) AppleWebKit/600,8 .9 (KHTML, wie Gecko) Version/8.0.8 Safari/600.8.9).

Wenn ich die Anfrage ohne xhr.withCredentials eingeschaltet mache, macht Safari zuerst eine OPTIONS Preflight Anfrage vor der eigentlichen Anfrage an DomainC, was IMHO nicht notwendig ist, da alle Anfragen einfache Anfragen sind, die ich aber behandeln kann. Problem ist, dass Safari nach einer Preflight-Anfrage an DomainC fehlschlägt, in der es heißt: "Kann keine Anfrage von null machen". Ich kann dies umgehen, indem ich Access-Control-Allow-Origin auf * setze und die Access-Control-Allow-Credentials-Header (diese schließen sich gegenseitig aus) fallen lassen, wodurch dieses Szenario funktioniert. Aber ich denke immer noch, dass das nicht korrekt ist.

Nun, ich brauche Anmeldeinformationen (und nein, ich kann es nicht anders weitergeben, da es auf einigen Servern von Drittanbietern abhängt). So lassen Sie sich gesetzt

xhr.withCredentials

zu wahren, und wir sind wieder auf „Kann keine Anfrage von null machen“ und jetzt auch von Platzhalter Access-Control-Allow-Credentials hilft nicht.

Ich denke, alle CORS-Header sind richtig eingestellt, aber bitte zögern Sie nicht mich zu überprüfen. Testbeispiel kann hier gefunden werden: http://a.ihatesafari.com

Was ist hier los? Ist es ein Käfer oder fehle ich etwas?

Danke für Antworten

Answer 1

ich dieses Problem wurde erlebt, wie gut und gefunden this bug von 2012, die beschreiben, es zu sein scheint. Das Ausführen des Testcodes, auf den im Fehler in FF/Chrome/Safari verwiesen wird, führte nur in Safari zu Fehlern. Es scheint, dass der Fehler nicht gepatcht wurde.

Um dies zu umgehen, änderte ich unsere HTTP-API, um einen optionalen Abfrageparameter hinzuzufügen, um eine andere Antwort auszulösen, die 200 OK mit einem JSON-Body zurückgab, der die URL enthielt, der der Client folgen sollte. Wenn Sie ein Verbraucher der HTTP-API einer anderen Person sind, hilft das leider nicht viel.