Red de conocimiento informático - Aprendizaje de programación - ¿La red tiene la misma solicitud dos veces? yo responderé

¿La red tiene la misma solicitud dos veces? yo responderé

Aparecieron dos solicitudes idénticas en la red (como se muestra en la imagen). Iniciaron la misma solicitud pero tardaron diferentes tiempos. Una tardó 55 ms y la otra 294 ms.

¿Qué está pasando? Después de investigar un poco, descubrí que una cosa es diferente: ¡Método de solicitud!

El método de solicitud con un tiempo de solicitud corto es OPCIONES y el valor de retorno está vacío.

El método de solicitud con un tiempo de solicitud prolongado es GET.

Originalmente pensé que las solicitudes ajax solo tenían dos métodos de solicitud: GET y POST, pero luego descubrí que existen diferencias entre HEAD, PUT, DELETE, OPTIONS...

Cuando ejecuto un proyecto de empresa en el entorno local, ¿por qué el navegador me envía en secreto una solicitud de OPCIONES que no regresa antes de cada POST?

Resulta que en algunas solicitudes, el navegador agregará una solicitud de consulta HTTP antes de la comunicación formal, lo que se denomina solicitud de "verificación previa".

El navegador primero pregunta al servidor si el nombre de dominio de la página web actual está en la lista de permisos del servidor y qué verbos HTTP y campos de información de encabezado se pueden usar. Solo cuando se recibe una respuesta positiva, el navegador emitirá una solicitud XMLHttpRequest formal; de lo contrario, se informará un error.

CORS es un estándar del W3C, su nombre completo es "Intercambio de recursos entre orígenes".

Permite que el navegador envíe solicitudes XMLHttpRequest a servidores de orígenes cruzados, superando así la limitación de que AJAX sólo se puede utilizar desde el mismo origen.

Los navegadores dividen las solicitudes CORS en dos categorías: solicitudes simples y solicitudes no tan simples.

Si se cumplen las siguientes condiciones al mismo tiempo, es una solicitud simple:

Para solicitudes simples, el navegador emite directamente una solicitud CORS. Específicamente, se trata de agregar un campo Origen a la información del encabezado.

El campo Origen se utiliza para indicar de qué fuente proviene esta solicitud (protocolo + nombre de dominio + puerto). El servidor decide si acepta la solicitud en función de este valor.

Si la fuente especificada por Origin no está dentro del rango de permiso, el servidor devolverá una respuesta HTTP normal. Cuando el navegador descubre que la información del encabezado de esta respuesta no contiene el campo Access-Control-Allow-Origin (ver detalles a continuación), sabe que algo salió mal y arroja un error, que es capturado por la función de devolución de llamada onerror de XMLHttpRequest . Tenga en cuenta que este error no se puede identificar mediante el código de estado, porque el código de estado de respuesta HTTP puede ser 200.

Si el nombre de dominio especificado por Origin está dentro del rango de permiso, la respuesta devuelta por el servidor tendrá varios campos de información de encabezado más. Todos comienzan con Access-Control-:

(1) Access-Control-Allow-Origin

Este campo es obligatorio. Su valor es el valor del campo Origen durante la solicitud o un *, que indica que se aceptan solicitudes de cualquier nombre de dominio.

Este campo es opcional. Su valor es un valor booleano que indica si se permite el envío de cookies. De forma predeterminada, las cookies no se incluyen en las solicitudes CORS. Establecido en verdadero, lo que significa que el servidor permite explícitamente que la cookie se incluya en la solicitud y se envíe al servidor.

Este valor solo se puede establecer en verdadero si el servidor no desea que el navegador envíe cookies, simplemente elimine este campo.

(3) Access-Control-Expose-Headers

Este campo es opcional. Al realizar una solicitud CORS, el método getResponseHeader() del objeto XMLHttpRequest solo puede obtener 6 campos básicos: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified y Pragma. Si desea obtener otros campos, debe especificarlos en Access-Control-Expose-Headers.

Las solicitudes no simples son solicitudes que tienen requisitos especiales para el servidor, como por ejemplo, el método de solicitud es PUT o DELETE, o el tipo del campo Tipo de contenido es aplicación/json.

Las solicitudes CORS que no son solicitudes simples agregarán una solicitud de consulta HTTP antes de la comunicación formal, denominada solicitud de "verificación previa".

El navegador primero pregunta al servidor si el nombre de dominio de la página web actual está en la lista de permisos del servidor y qué verbos HTTP y campos de información de encabezado se pueden utilizar. Solo cuando se reciba una respuesta positiva el navegador emitirá una solicitud XMLHttpRequest formal; de lo contrario, se informará un error.

Cuando el nombre de dominio de la página y el nombre de dominio de la interfaz son inconsistentes, existe el problema de enviar una solicitud de opciones antes de cada solicitud.

Además del campo Origen, la información del encabezado de solicitud de OPCIONES tendrá al menos dos campos especiales más:

(1) Método-de-solicitud-de-control de acceso

Este campo es obligatorio y se utiliza para enumerar qué métodos HTTP utilizará el navegador para las solicitudes CORS.

(2) Access-Control-Request-Headers

Este campo es una cadena separada por comas que especifica campos de información de encabezado adicionales que el navegador enviará en las solicitudes CORS.

En cuanto a otros campos complicados, todavía no los uso ni los entiendo, y aprenderé más sobre ellos gradualmente.

Después de que el servidor recibe la solicitud de verificación previa, verifica los campos Origen, Método de solicitud de control de acceso y Encabezados de solicitud de control de acceso, confirma que las solicitudes de origen cruzado están permitidas y puede responder.

En la respuesta HTTP anterior, la clave es el campo Access-Control-Allow-Origin, que indica que se pueden solicitar datos. Este campo también se puede configurar con un asterisco para aceptar cualquier solicitud de origen cruzado.

Si el navegador rechaza la solicitud de "verificación previa", se devolverá una respuesta HTTP normal, pero sin ningún campo de encabezado relacionado con CORS. En este momento, el navegador determinará que el servidor no está de acuerdo con la solicitud de verificación previa, por lo que se activa un error, que es capturado por la función de devolución de llamada onerror del objeto XMLHttpRequest. La consola imprimirá el siguiente mensaje de error.

XMLHttpRequest no se puede cargar

Access-Control-Allow-Origin no permite el origen

Access-Control-Max-Age se utiliza para especificar otros campos. El período de validez de esta solicitud de verificación previa, en segundos. Este campo es opcional.

CORS se utiliza para el mismo propósito que JSONP, pero es más potente que JSONP.

JSONP solo admite solicitudes GET. La ventaja de JSONP es que admite navegadores antiguos.

Resuelva el problema de que la misma solicitud aparezca dos veces en la Red. No lo encontrará utilizando solicitudes simples.