2011-12-30 3 views
6

Sto esaminando i problemi relativi ai domini incrociati, ho qualche chiamata di servizio REST. Chrome ha detto questo: richiesta campo di intestazione x-richiesta-con non è consentita da Access-Control-Allow-intestazioni Questo è quello che ho ottenuto dalla rete -> Intestazioni scheda:Servizio REST AJAX per il dominio incrociato Intestazioni HTTP

Request URL: rest_url_on_other_domain 
Request Method:OPTIONS 
Status Code:200 OK 
Request Headers: 
Access-Control-Request-Headers:Origin, x-requested-with, content-type, accept 
Access-Control-Request-Method:POST 
Origin:http://localhost:8080 

Response Headers 
Access-Control-Allow-Headers:Content-Type, Accept 
Access-Control-Allow-Methods:GET, POST 
Access-Control-Allow-Origin:* 
Access-Control-Max-Age:1728000 
Cache-Control:no-cache, no-store 
Connection:keep-alive 
Content-Length:0 
Date:Fri, 30 Dec 2011 11:29:12 GMT 
Expires:-1 
Pragma:no-cache 
Server:nginx/1.0.2 

Could qualcuno ti spiega queste intestazioni HTTP? Qual è il problema - Alcune intestazioni verificano il fallimento del server o alcune intestazioni di controllo sul lato client (browser) non riescono. Qual è l'idea di queste intestazioni di Access? Spiega in dettaglio in parole semplici solo per avere la sensazione del resto imparerò da me stesso. Grazie in anticipo!

risposta

11

Quello che stai vedendo è una richiesta di verifica preliminare per la condivisione delle risorse tra origini. Il metodo di richiesta per tale richiesta è OPTIONS. Questa è una richiesta che il browser utilizza per chiedere le autorizzazioni per inviare la richiesta effettiva. Potete saperne di più qui: http://www.html5rocks.com/en/tutorials/cors/

In questo caso particolare, il browser chiede una serie di intestazioni (nell'intestazione Access-Control-Request-Headers). Ora, in risposta, l'intestazione Access-Control-Allow-Headers dovrebbe contenere tutte le intestazioni richieste. Nel caso, se ci sono più di intestazioni richieste, il browser non genererà alcuna eccezione. In questo esempio, l'intestazione della risposta dovrebbe avere il seguente aspetto:

Access-Control-Allow-Headers: Origin, x-requested-with, content-type, accept 

Tutte le altre intestazioni di risposta sembrano ok. Una volta che il server invia questa risposta, il browser invierà una seconda richiesta, che è la richiesta effettiva per i dati.

+1

Ma qual è l'idea di richiedere il preflight - quali informazioni otterrà da queste intestazioni. La conversazione è simile alla richiesta di preflight (Origin Header- "Quali domini supportate", x-request-with - "Supporta XMLHttpRequests?", ...) e quando vengono ripetuti nella risposta di preflight che significa "Sì "a tutti loro o è brutto avere una simile analogia. E quando il browser invia la richiesta reale - quando le condizioni sono soddisfatte (esempio semplice mb). Grazie! – EnTrERy

+1

Il preflight è il browser chiede: "Ciao server! Ho una richiesta qui, è da questo dominio, sta usando questo metodo http, e ha queste intestazioni di richiesta. È bello se invio la richiesta effettiva?" Il server quindi conferma la richiesta di preflight rinviando le intestazioni Access-Control-Allow- *. La ragione per cui utilizza queste intestazioni piuttosto che un semplice OK è che la risposta di preflight può essere memorizzata nella cache dopo la prima richiesta. In questo modo non è necessario emettere un preflight su ogni richiesta, risparmiando così la larghezza di banda. – monsur

+1

Grazie mille per la spiegazione dettagliata! – EnTrERy