CORS post z żądaniem preflight

Question

Próbuję przesłać pliki do usługi w innej domenie przy użyciu CORS, ale nadal nie działają z powodu odmowy pochodzenia. O ile widzę, używa się odpowiednich nagłówków, aby to umożliwić.

JavaScript prośba:

var xhr = new XMLHttpRequest(); 
    xhr.open('POST', "https://files.example.com", true);                                
    xhr.setRequestHeader('Content-Type', 'application/json'); 
    xhr.onreadystatechange = function() { 
    if (this.status == 200 && this.readyState == 4) { 
     console.log('response: ' + this.responseText); 
    } 
    }; 

    xhr.send(); 

Response z prefligtu OPCJE życzenie:

Access-Control-Allow-Headers:Origin, Authorization, Content-Type 
Access-Control-Allow-Methods:POST, OPTIONS 
Access-Control-Allow-Origin:* 
Content-Length:0 
Content-Type:application/json 
Date:Mon, 19 Nov 2012 23:30:21 GMT 

nagłówki POST życzenie:

Cache-Control:no-cache 
Content-Type:application/json 
Origin:https://www.example.com 
Pragma:no-cache 
Referer:https://www.example.com 
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/537.19 (KHTML, like  Gecko) Chrome/25.0.1325.0 Safari/537.19 

co powoduje błąd:

XMLHttpRequest cannot load https://files.example.com. Origin https://www.example.com is not allowed by Access-Control-Allow-Origin. 

Answer 1

Spróbuj dodać Cache-Control i Pragma do listy dozwolonych nagłówków w preflight. Pełny nagłówek powinien wyglądać tak:

Access-Control-Allow-Headers: Cache-Control, Pragma, Origin, Authorization, Content-Type 

Answer 2

Subdomeny są różne. Jeśli chodzi o CORS, poddomena, protokół i port muszą być identyczne w Origin i Access-Control-Allow-Origin.

W przykładzie wygląda pochodzenie jest: https://www.example.com i Access-Control-Allow-Origin: https://files.example.com

Answer 3

Niestety, wysyłanie do domeny innej niż Twoja strona użytkownika wywołuje CORS. Obejmuje to również różne subdomeny, porty i protokoły (http/https).

Inspekcja wstępna jest wykonywana, gdy żądanie jest "nie proste", co oznacza, że ​​nagłówek treści jest ustawiony na coś innego niż "tekst/zwykły". Twoja "aplikacja/json" powoduje, że przeglądarki zaczynają się bać w preflighting.

Jeśli te 50-200 ms są dla Ciebie ważne, możesz przepisać swoją usługę internetową, aby zrozumieć "prosty" typ zawartości. Jeśli nie, to powinieneś sprawić, by usługa sieci Web odrzuciła stan HTTP 204 (brak treści), gdy zostanie mu przypisana opcja OPCJE (metoda http).

Gdy mamy do czynienia z WCF:

WebOperationContext.Current.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.NoContent; 

Answer 4

To trochę późno, ale patrząc na informacji pokazuje pre-lot check CORS działa OK, to po prostu rzeczywista (2) CORS prośba gdzie odpowiedź dostaje zablokowane przez przeglądarkę.

Szkoda, że ​​nie uwzględniono odpowiedzi na faktyczne (drugie) żądanie CORS, ponieważ mogło to zawierać wskazówkę dotyczącą odrzucenia odpowiedzi. Podejrzewam, że chociaż odpowiedź przed lotem prawidłowo zawiera nagłówek:

Access-Control-Allow-Origin:* 

... rzeczywisty (2) odpowiedź może nie zawierały że nagłówek, w którym to przypadku przeglądarka poprawnie odrzuca odpowiedź. Jeśli moje założenie jest prawdziwe, rozwiązaniem byłoby włączenie tego nagłówka również w rzeczywistą odpowiedź (nie przed lotem).