CORS funktioniert nicht in Firefox

Ich versuche, Daten in einem jQuery-Dialog über Ajax zu laden, aber die Anfrage schlägt in Firefox (34.0.5). Funktioniert gut und ich habe keine Beschwerden in Chrome und Safari.CORS funktioniert nicht in Firefox

Meine Apache conf enthält:

Header set Access-Control-Allow-Origin "*" 
Header set Access-Control-Allow-Methods: "PUT, GET, POST, DELETE, OPTIONS" 
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"

Die jQuery ist einfach:

$('#dialog').load('example.php', function() { $('#dialog').dialog('open'); });

Firefox reagiert mit der folgenden Konsole Fehler:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://www.example.com/example.php. This can be fixed by moving the resource to the same domain or enabling CORS.

Inspizieren die Response-Header aus die Ajax-Anfrage scheinen alle intakt zu sein Inline mit dem, was in Apache deklariert ist. Sollte ich irgendeine andere Anweisung einbeziehen oder die Konfiguration in irgendeiner Weise ändern, damit dies funktioniert?

UPDATE: Die Ursache des Problems ist die Tatsache, dass ich sowohl example.com als auch www.example.com die gleiche Funktion haben möchte. Die betreffende Site hat in beiden Fällen immer einen Tag in der Kopfzeile <base href="www.example.com" />, da dies Teil des Standard-Site-Frameworks ist. Ich habe seitdem entdeckt, dass das Entfernen dieser Verbindung es der Ajax-Anfrage ermöglicht, auf example.com zu arbeiten, selbst wenn sie noch spezifisch eine Ressource von der www-Subdomain aufruft.

Interessanterweise ändern sich viele Aspekte der Anforderungs- und Antwortheader, wenn dieses Tag entfernt wird. Für jeden, der eine Ahnung von den Implikationen hat, gebe ich hier sowohl die Anforderungs- als auch die Antwort-Header ein.

Hier sind die Header mit <base> Tag entfernt. In diesem Fall war der Ajax-Aufruf erfolgreich:

RESPONSE

HTTP/1.1 200 OK 
    Date: Sun, 18 Jan 2015 22:11:04 GMT 
    Server: Apache/2.4.7 (Ubuntu) 
    X-Powered-By: PHP/5.5.9-1ubuntu4.5 
    Set-Cookie: PHPSESSID=xxx; path=/; HttpOnly 
    language=en; expires=Tue, 17-Feb-2015 22:11:04 GMT; Max-Age=2592000; path=/; domain=www.example.com 
    currency=CAD; expires=Tue, 17-Feb-2015 22:11:04 GMT; Max-Age=2592000; path=/; domain=www.example.com 
    Expires: Thu, 19 Nov 1981 08:52:00 GMT 
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, public 
    Pragma: no-cache 
    Content-Encoding: gzip 
    access-control-allow-methods: PUT, GET, POST, DELETE, OPTIONS 
    access-control-allow-origin: * 
    access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept 
    Content-Length: 1515 
    Connection: close 
    Content-Type: text/html; charset=utf-8

REQUEST

GET /example.php HTTP/1.1 
    Host: www.example.com 
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:34.0) Gecko/20100101 Firefox/34.0 FirePHP/0.7.4 
    Accept: text/html, */*; q=0.01 
    Accept-Language: en-US,en;q=0.5 
    Accept-Encoding: gzip, deflate 
    Referer: http://example.com/ 
    Origin: http://example.com 
    x-insight: activate 
    Connection: keep-alive 
    Cache-Control: max-age=0

Und hier die Header mit dem <base> Tag intakt sind. Diese Header geben das Szenario wieder, in dem der Ajax-Aufruf fehlgeschlagen ist. Es ist erwähnenswert, dass die 'Location' Feld in der Antwort-Header sagt 'https', obwohl dies nicht wurde eine https-Verbindung geschieht über:

RESPONSE

HTTP/1.1 302 Found 
    Date: Sun, 18 Jan 2015 22:12:26 GMT 
    Server: Apache/2.4.7 (Ubuntu) 
    X-Powered-By: PHP/5.5.9-1ubuntu4.5 
    Set-Cookie: PHPSESSID=xxx; path=/; HttpOnly 
    language=en; expires=Tue, 17-Feb-2015 22:12:26 GMT; Max-Age=2592000; path=/; domain=www.example.com 
    currency=CAD; expires=Tue, 17-Feb-2015 22:12:26 GMT; Max-Age=2592000; path=/; domain=www.example.com 
    Expires: Thu, 19 Nov 1981 08:52:00 GMT 
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, public 
    Pragma: no-cache 
    Status: 302 
    Location: https://www.example.com/index.php 
    access-control-allow-methods: PUT, GET, POST, DELETE, OPTIONS 
    access-control-allow-origin: * 
    access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept 
    Content-Length: 0 
    Connection: close 
    Content-Type: text/html

REQUEST

OPTIONS /example.php HTTP/1.1 
    Host: www.example.com 
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:34.0) Gecko/20100101 Firefox/34.0 FirePHP/0.7.4 
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
    Accept-Language: en-US,en;q=0.5 
    Accept-Encoding: gzip, deflate 
    Origin: http://example.com 
    Access-Control-Request-Method: GET 
    Access-Control-Request-Headers: x-requested-with 
    x-insight: activate 
    Connection: keep-alive 
    Cache-Control: max-age=0

Quelle

2015-01-18 billynoah

Werden die CORS-Header zweimal gesendet? Ich hatte ein neues Problem, wo ich es irrtümlich zu meinem htaccess sowie meinem Apache conf hinzugefügt hatte. Dies führte dazu, dass die Headerwerte zweimal gesendet wurden, was dazu führte, dass einige Browser nicht ordnungsgemäß funktionierten. – JohnP

Nicht, dass ich sehen kann. Ich habe nichts eingestellt in .htaccess nur Apache vhost conf - obwohl ich denke, dass es auch passieren kann, wenn Sie 'Header add 'anstelle von' Header set' verwenden. Wie es aussieht, sehe ich sie nur einmal in den Antwortheadern. – billynoah

Ich habe ähnliches Problem (das funktioniert auf Chrome, nicht in FF), aber ohne Tag verwendet wird. – aesede

Laut MDN können Sie den Platzhalter nicht für "credentialed requests" verwenden. Daher fällt Ihre Anfrage möglicherweise in diese Kategorie.

Quelle

2016-03-25 15:09:02 thelr

CORS funktioniert nicht in Firefox

Antwort

Verwandte Themen