2011-12-30 11 views
6

Estoy investigando los problemas de Dominios cruzados, tengo con alguna llamada de servicio REST. Chrome dijo lo siguiente: Solicitud solicitó-x-con campo de cabecera no está permitido por Access-Control-Allow-encabezados Esto es lo que he conseguido de Red -> pestaña Encabezados:Dominio cruzado AJAX del servicio REST encabezados 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 

Podría Alguien explica acerca de este encabezado HTTP? ¿Cuál es el problema? Algunos encabezados verifican que el servidor falle o algunos encabezados verifican que el cliente (navegador) falle. ¿Cuál es la verdadera idea sobre estos encabezados de acceso? Explicar en detalle con palabras sencillas solo para obtener la sensación del resto, lo aprenderé por mi cuenta. ¡Gracias por adelantado!

Respuesta

11

Lo que está viendo es una solicitud de verificación previa de uso compartido de recursos entre orígenes. El método de solicitud para dicha solicitud es OPTIONS. Esta es una solicitud que el navegador usa para solicitar permisos para enviar la solicitud real. Puede obtener más información aquí: http://www.html5rocks.com/en/tutorials/cors/

En este caso particular, el navegador solicita varios encabezados (en el encabezado Access-Control-Request-Headers). Ahora, en respuesta, el encabezado Access-Control-Allow-Headers debe contener todos los encabezados solicitados. En el caso, si hay más de los encabezados solicitados, el navegador no lanzará ninguna excepción. En este ejemplo, su encabezado de respuesta debe verse así:

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

Todos los demás encabezados de respuesta se ven bien. Una vez que el servidor envía esta respuesta, el navegador enviará una segunda solicitud, que es la solicitud real de los datos.

+1

Pero, ¿cuál es la idea de la solicitud de verificación previa? ¿Qué información obtendrá de estos encabezados? ¿Es la conversación como: solicitud de verificación previa (encabezado de origen- "¿Qué dominios admite?", "X-requested-with" - "¿Admite XMLHttpRequests?", ...) y cuando se repiten en la respuesta de verificación previa que significa "Sí". "a todos ellos o es malo tener tal analogía. Y cuando el navegador envía la solicitud real, ¿qué condiciones se cumplen? (Ejemplo simple). ¡Gracias! – EnTrERy

+1

La verificación previa es el navegador que pregunta: "Hola servidor! Tengo una solicitud aquí, es de este dominio, está utilizando este método http, y tiene estos encabezados de solicitud. ¿Es genial si envío la solicitud real?" El servidor confirma la solicitud de verificación previa devolviendo los encabezados Access-Control-Allow- *. La razón por la que utiliza estos encabezados en lugar de un simple OK es que la respuesta de verificación previa se puede almacenar en caché después de la primera solicitud. De esta forma, no se debe emitir una verificación previa en cada solicitud, lo que ahorra ancho de banda. – monsur

+1

¡Muchas gracias por la explicación detallada! – EnTrERy

Cuestiones relacionadas