[Notas de la red informática 5] Mensaje HTTP de capa de aplicación (2)

formato de mensaje HTTP

Las estructuras de los mensajes de solicitud y los mensajes de respuesta del protocolo HTTP son básicamente las mismas y constan de cuatro partes:

• ① Línea de inicio : Describe la información básica de la solicitud o respuesta;
• ② Conjunto de campos de encabezado (encabezado) : utilice key-valueel formulario para describir el mensaje con más detalle;
• ③ Línea en blanco + retorno de carro CRLF y avance de línea
• ④ Cuerpo del mensaje (cuerpo) : Los datos reales transmitidos no son necesariamente texto sin formato, pueden ser datos binarios como imágenes y videos.

HTTP es un protocolo de "texto sin formato", por lo que los datos del encabezado son texto ASCII y se pueden leer fácilmente a simple vista.

Solicitar formato de mensaje:

Formato del mensaje de respuesta:

Nota: Según RFC 2616 (HTTP/1.1), en el campo de encabezado, puede haber uno o más espacios opcionales delante del valor del campo, pero no puede haber espacios en el nombre del campo y entre el nombre del campo y el nombre del campo. :. Es por eso que los paquetes HTTP obtenidos por las herramientas de desarrollo del navegador y algunas herramientas de captura de paquetes son versiones más legibles con espacios.

Solicitar línea de mensaje de solicitud

La línea de solicitud describe brevemente cómo el cliente quiere operar en el recurso del lado del servidor.

La línea de solicitud consta de tres partes: método de solicitud + URI + + número de versión +空格空格CRLF回车换行

• ① Método de solicitud : es un verbo, como GET / POST , que indica el método de operación de los recursos;
• ② Destino de la solicitud : la ruta del destino de la solicitud, generalmente un URI , que marca el recurso que será operado por el método de solicitud;
• ③ Número de versión : indica la versión del protocolo HTTP utilizada por el mensaje , como HTTP/1.1.

Estas tres partes suelen estar separadas por espacios :

URI : Identificador uniforme de recursos (Identificador uniforme de recursos)

Línea de estado del mensaje de respuesta

Aquí no se llama " línea de respuesta ", sino " línea de estado ", que significa el estado de la respuesta del servidor.

La línea de estado consta de tres partes: número de versión + 空格+ código de estado + 空格+ motivo +CRLF回车换行

• ① Número de versión : indica la versión del protocolo HTTP utilizada por el mensaje , como HTTP/1.1;
• ② Código de estado : un número de 3 dígitos que indica el resultado del procesamiento, como 200 éxito, 500 error del servidor, 404 el recurso no existe;
• ③ Descripción del motivo : como complemento del código de estado digital, es un texto explicativo más detallado para ayudar a las personas a comprender el motivo.

campo de encabezado

El protocolo HTTP especifica una gran cantidad de campos de encabezado para implementar varias funciones, pero básicamente se pueden dividir en cuatro categorías:

• ① Campos comunes : pueden aparecer tanto en encabezados de solicitud como en encabezados de respuesta; por ejemplo Date,Connection

• ② Campo de solicitud : solo puede aparecer en el encabezado de la solicitud para describir con más detalle la información de la solicitud o condiciones adicionales adicionales, como Host, Acceptetc.

• ③ Campo de respuesta : solo puede aparecer en el encabezado de respuesta y complementar la información del mensaje de respuesta; por ejemplo, Serveretc.

• ④ Campo de entidad : En realidad es un campo general , pero describe específicamente información adicional del cuerpo . Por ejemplo, Content-Lengthespera

El análisis y procesamiento de mensajes HTTP en realidad se trata principalmente del procesamiento de campos de encabezado. Comprender los campos de encabezado también significa comprender los mensajes HTTP.

Campos de encabezado de uso común: campo de host

• Host es un campo de solicitud y solo puede aparecer en el encabezado de la solicitud.

• Host también es el único campo que debe aparecer en la especificación HTTP/1.1 . Es decir, si no hay Host en el encabezado de la solicitud, entonces se trata de un mensaje de error .

• El campo Host en realidad le dice al servidor en qué host se debe procesar esta solicitud.
  
  

Campos de encabezado de uso común: campo Usuario-Agente

• User-Agent es un campo de solicitud que solo aparece en el encabezado de la solicitud .

• Utiliza una cadena para describir el cliente que inició la solicitud HTTP y el servidor puede usarla para devolver la página más adecuada para este navegador.
  
  

Campos de encabezado de uso común: campo de fecha

• El campo Fecha es un campo general, pero generalmente aparece en el encabezado de respuesta , indicando la hora en que se creó el mensaje HTTP . El cliente puede usar esta hora en combinación con otros campos para determinar la estrategia de almacenamiento en caché.

Campos de encabezado de uso común: campo de servidor

• El campo Servidor es un campo de respuesta y solo puede aparecer en el encabezado de respuesta. Le dice al cliente el nombre y el número de versión del software que actualmente proporciona el servicio web.

• El campo Servidor no tiene que aparecer porque expondrá parte de la información del servidor al mundo exterior. Si hay un error en esta versión, los piratas informáticos pueden utilizar el error para comprometer el servidor. Por lo tanto, algunos sitios web no tienen este campo en el encabezado de respuesta o brindan información descriptiva completamente irrelevante.

Campos de encabezado de uso común: campo Longitud del contenido

• Uno de los campos de entidad del que hablar es Content-Length , que representa la longitud del cuerpo del mensaje , es decir, la longitud de los datos después de la línea en blanco en el encabezado de la solicitud o el encabezado de la respuesta.

• Cuando el servidor ve este campo, sabe cuántos datos seguirán y puede recibirlos directamente. Si no existe tal campo, entonces el cuerpo tiene una longitud variable y debe transmitirse en fragmentos utilizando el método fragmentado .

campos de encabezado relacionados con el cuerpo

• Aceptar: indica los tipos de datos que el cliente puede analizar. Se pueden enumerar varios tipos separados por comas.

• Accept-Encoding: indica el formato de compresión admitido por el cliente, que se puede omitir (sin compresión)

• Accept-Language: Idioma soportado por el cliente

• Accept-Charset: generalmente no se envía, los navegadores admiten múltiples conjuntos de caracteres

• Tipo de contenido: el tipo verdadero de la entidad de respuesta, que puede aparecer en los encabezados de solicitud y de respuesta.

• Codificación de contenido: el servidor le dice al cliente qué algoritmo de compresión se utiliza para la entidad de respuesta, cuál se puede omitir (sin compresión)

• Idioma de contenido: generalmente no lo envía el servidor, indica el idioma utilizado, que generalmente se puede inferir del conjunto de caracteres en Tipo de contenido, como Tipo de contenido: texto/html; charset=utf-8

• Codificación de transferencia: fragmentado: indica transferencia fragmentada. Cada fragmento contiene dos partes: encabezado de longitud y bloque de datos. La longitud del último fragmento es 0 para indicar el final, es decir, "0\r\n\r\n"

  Codificación de transferencia: los campos fragmentados y Longitud del contenido son mutuamente excluyentes y estos dos campos no pueden aparecer al mismo tiempo en el mensaje de respuesta.

tipo de datos del cuerpo

Los cuatro tipos de datos comúnmente utilizados en HTTP incluyen: text, image, audio/video,application

Cada categoría principal se subdivide en múltiples subcategorías, en forma de type／subtypeuna cadena de " "

• ① text: Datos legibles en formato de texto, como text/htmlhipertexto, text/plaintexto sin formato, text/csshojas de estilo, etc.

• ② image: Archivos de imagen, como image/gif, image/jpeg, image/pngetc.

• ③ audio/video: Datos de audio y vídeo, como audio/mpeg, video/mp4etc.

• ⑤ application: El formato no es fijo y puede ser texto o binario. Debe ser interpretado por la aplicación de la capa superior. Los más comunes incluyen application/json, application/javascript, application/pdfetc.

  Si no sabe de qué tipo son los datos, utilice application/octet-streamdatos binarios opacos.

compresión de datos corporales

Algoritmo de compresión:

• ① gzip: formato de compresión zip GUN, el algoritmo de compresión más popular en Internet
• ② deflate: zlibFormato de compresión
• ③ br: Un nuevo algoritmo de compresión especialmente optimizado para http

Comprima los campos de encabezado correspondientes:

• El campo Aceptar marca los tipos de datos que el cliente puede analizar y se puede utilizar ,como separador para enumerar varios tipos, lo que le da al servidor más opciones.

  El campo Aceptar en la imagen de arriba le dice al servidor: "Puedo entender HTML, texto json e imágenes webp y png. Por favor, proporcione datos en estos cuatro formatos".

• El campo Aceptar-Codificación marca el formato de compresión admitido por el cliente.

• Codificación de contenido : el servidor puede elegir uno de los formatos de compresión descritos en el campo Codificación de aceptación para comprimir datos. El formato de compresión real utilizado se coloca en el campo Codificación de contenido del encabezado de respuesta.
  
  

Se pueden omitir tanto Accept-Encoding como Content-Encoding , es decir, no se realiza ninguna compresión.

tipo de lenguaje corporal/codificación de conjunto de caracteres

Campo de encabezado correspondiente:

Sin embargo, los navegadores actuales admiten múltiples conjuntos de caracteres y generalmente no envían Accept-Charset , y el servidor no envía Content-Language , porque el idioma utilizado se puede inferir del conjunto de caracteres, por lo que el encabezado de la solicitud generalmente solo contiene el campo Accept-Language. , solo habrá un campo Tipo de contenido en el encabezado de respuesta.

contenido del cuerpo valor de calidad negociado

Cuando utilice Accept , Accept-Encoding , Accept-Language y otros campos de encabezado de solicitud para la negociación de contenido en el protocolo HTTP , también puede usar un qparámetro " " especial para representar el peso para establecer la prioridad . La " " aquí qes la "calidad factor "el significado de.

El valor máximo del peso es 1, el valor mínimo es 0.01y el valor predeterminado es 1, si el valor es, 0significa rechazo. La forma específica es agregar un " " después del tipo de datos o código de idioma ;y luego seguirlo con " q=value".

Significa que el navegador quiere utilizar htmlmás archivos, con un peso de 1, seguidos de xmlarchivos, con un peso de 0.9, y finalmente cualquier tipo de datos */*, con un peso de 0.8.

Una vez que el servidor recibe el encabezado de la solicitud, calculará el peso y luego generará HTML o XML primero de acuerdo con su situación real.

transferencia fragmentada

"Codificación de transferencia: fragmentada" significa que la parte del cuerpo del mensaje no se envía a la vez, sino que se divide en muchos fragmentos y se envía uno por uno.

Nota: Los dos campos "Codificación de transferencia: fragmentado" y "Longitud del contenido" son mutuamente excluyentes. Estos dos campos no pueden aparecer al mismo tiempo en el mensaje de respuesta, porque la longitud de un mensaje de respuesta es conocida o desconocida (fragmentada) . ).

Obtener datos por rango

• Accept-Range: bytes aparece en el mensaje de respuesta, lo que indica que el servidor admite la recuperación de datos de rango por bytes.
• Rango: bytes= <start>- <end>Aparece en el mensaje de solicitud, indicando qué dato se va a recuperar
• Rango de contenido: <start>- <end>/total aparece en el mensaje de respuesta, indicando qué datos se envían.

Usos principales: descarga de currículum de punto de interrupción, descarga multiproceso.

método de solicitud HTTP

Actualmente, HTTP/1.1 estipula ocho métodos de solicitud y todas las palabras deben estar en mayúsculas:

• ① OBTENER : Obtener recursos, que puede entenderse como leer o descargar datos;
• ② HEAD : obtiene metainformación de recursos;
• ③ POST : enviar datos a recursos, lo que equivale a escribir o cargar datos;
• ④ PUT : similar a POST;
• ⑤ BORRAR : eliminar recursos;
• ⑥ CONECTAR : Establecer un túnel de conexión especial;
• ⑦ OPCIONES : Enumere los métodos que se pueden realizar en el recurso;
• ⑧ TRACE : ruta de transmisión de solicitud-respuesta de seguimiento.

OBTENER y CABEZA

• El significado de GET es solicitar obtener recursos del servidor, que pueden ser texto estático, páginas, imágenes, videos o páginas o datos generados dinámicamente en otros formatos mediante PHP o Java.

• El método HEAD es similar al método GET . También solicita recursos del servidor. El mecanismo de procesamiento del servidor es el mismo, pero el servidor no devolverá los datos de la entidad solicitada, solo devolverá el encabezado de respuesta, que es la "metainformación". " del recurso.

Por ejemplo, si desea verificar si un archivo existe, solo necesita enviar una solicitud HEAD y no es necesario usar GET para recuperar el archivo completo. Para otro ejemplo, si desea verificar si un archivo tiene la última versión, también debe usar HEAD El servidor devolverá la hora de modificación del archivo en el encabezado de respuesta.

PUBLICAR y PONER

• POST también es un método de solicitud de uso frecuente. La frecuencia de uso debe ser superada solo por GET . También hay muchos escenarios de aplicación. Siempre que los datos se envíen al servidor, se usa principalmente POST .

• PUT tiene una función similar a POST y también puede enviar datos al servidor, pero es sutilmente diferente de POST. Por lo general, POST significa " nuevo " y " crear ", mientras que PUT significa " modificar " y " actualizar ".

En aplicaciones prácticas, PUT rara vez se utiliza. Además, debido a que su semántica y funciones son demasiado similares a POST , algunos servidores incluso prohíben directamente el uso del método PUT y solo usan el método POST para cargar datos.

Código de estado de respuesta

El código de estado especificado actualmente en el estándar RFC es de tres dígitos , por lo que el rango de valores es[000~999]

El estándar RFC divide los códigos de estado en cinco categorías . El primer dígito del número se utiliza para indicar la categoría en lugar 0~99de . De esta manera, el rango real utilizable de códigos de estado se reduce considerablemente, [000~999]desde [100~599].

Los significados específicos de estas cinco categorías son:

• 1xx: mensaje rápido, que indica que el procesamiento del protocolo actual se encuentra en un estado intermedio y se requieren operaciones posteriores;
• 2xx: Éxito, el mensaje ha sido recibido y procesado correctamente;
• 3xx: Redirección, la ubicación del recurso cambia y el cliente necesita reenviar la solicitud;
• 4xx: error del cliente, el mensaje de solicitud es incorrecto y el servidor no puede procesarlo;
• 5xx: Error del servidor. Se produjo un error interno mientras el servidor procesaba la solicitud.

Detalles del código de estado

código de estado	información de estado	significado
100	Continuar	La solicitud inicial ha sido aceptada y el cliente deberá continuar enviando el resto de la solicitud. (Nuevo en HTTP 1.1)
101	Protocolos de conmutación	El servidor cumplirá con la solicitud del cliente y cambiará a otro protocolo (nuevo en HTTP 1.1).
102	Procesando	Un código de estado extendido por WebDAV (RFC 2518) que indica que el procesamiento continuará.
200	DE ACUERDO	Todo funciona bien, siguen los documentos de respuesta a las solicitudes GET y POST.
201	Creado	El servidor ha creado el documento y su URL se proporciona en el encabezado Ubicación.
202	Aceptado	La solicitud ha sido aceptada, pero el procesamiento aún no se ha completado.
203	Información no autorizada	El documento se devolvió normalmente, pero algunos encabezados de respuesta pueden ser incorrectos porque se utiliza una copia del documento (nuevo en HTTP 1.1).
204	Sin contenido	Sin un documento nuevo, el navegador debería seguir mostrando el documento original. Este código de estado es útil si el usuario actualiza la página periódicamente y el servlet puede determinar que el documento del usuario está lo suficientemente actualizado.
205	Restablecer contenido	No hay contenido nuevo, pero el navegador debería restablecer lo que muestra. Se utiliza para obligar al navegador a borrar el contenido de entrada del formulario (nuevo en HTTP 1.1).
206	Contenido parcial	El cliente envía una solicitud GET con un encabezado Range y el servidor la completa (nuevo en HTTP 1.1).
207	Estado múltiple	El código de estado extendido por WebDAV (RFC 2518) significa que el cuerpo del mensaje posterior será un mensaje XML y puede contener una serie de códigos de respuesta independientes dependiendo del número de subsolicitudes anteriores.
300	Múltiples opciones	El documento solicitado por el cliente se puede encontrar en múltiples ubicaciones, las cuales se enumeran dentro del documento devuelto. Si el servidor quiere proponer una preferencia, deberá indicarlo en el encabezado de respuesta Ubicación.
301	Movido permanentemente	El documento solicitado por el cliente está en otro lugar, la nueva URL se proporciona en el encabezado Ubicación y el navegador debería acceder automáticamente a la nueva URL.
302	Encontró	Similar al 301, pero la nueva URL debe considerarse un reemplazo temporal en lugar de permanente. Tenga en cuenta que la información de estado correspondiente en HTTP 1.0 es "Movido temporalmente". Cuando aparece este código de estado, el navegador puede acceder automáticamente a la nueva URL, por lo que es un código de estado útil. Tenga en cuenta que este código de estado a veces se puede usar indistintamente con 301. Por ejemplo, si el navegador solicita por error http://host/~user (faltando la barra diagonal), algunos servidores devolverán 301 y otros 302. Estrictamente hablando, sólo podemos asumir que el navegador redirigirá automáticamente sólo si la solicitud original fue un GET. Ver 307.
303	Ver Otros	Similar a 301/302, excepto que si la solicitud original fue una POST, el documento de destino de redirección especificado por el encabezado Ubicación debe recuperarse mediante GET (nuevo en HTTP 1.1).
304	No modificado	El cliente tiene un documento almacenado en búfer y realiza una solicitud condicional (generalmente proporcionando un encabezado If-Modified-Since para indicar que el cliente solo quiere documentos que sean más recientes que la fecha especificada). El servidor le dice al cliente que el documento original almacenado en el búfer puede seguir utilizándose.
305	Usa proxy	Los documentos solicitados por el cliente deben recuperarse a través del servidor proxy especificado en el encabezado Ubicación (nuevo en HTTP 1.1).
306	Cambiar proxy	En la última versión de la especificación, el código de estado 306 ya no se utiliza.
307	Redirección temporal	Igual que 302 (Encontrado). Muchos navegadores redireccionarán incorrectamente con una respuesta 302, incluso si la solicitud original fue una POST, aunque en realidad solo pueden redireccionar si la respuesta a una solicitud POST es una 303. Por esta razón, HTTP 1.1 agregó 307 para distinguir más claramente entre varios códigos de estado: cuando ocurre una respuesta 303, el navegador puede seguir las solicitudes GET y POST redirigidas; si es una respuesta 307, el navegador solo puede seguir la redirección de solicitudes GET. (Nuevo en HTTP 1.1)
400	Solicitud incorrecta	Se produjo un error de sintaxis con la solicitud.
401	No autorizado	Un cliente intentó obtener acceso no autorizado a una página protegida con contraseña. La respuesta contendrá un encabezado WWW-Authenticate y el navegador mostrará el cuadro de diálogo de nombre de usuario/contraseña correspondiente y luego realizará la solicitud nuevamente después de completar el encabezado de Autorización apropiado.
402	pago requerido	Este código de estado está reservado para posibles necesidades futuras.
403	Prohibido	El recurso no está disponible. El servidor comprende la solicitud del cliente pero se niega a procesarla. Generalmente causado por la configuración de permisos de archivos o directorios en el servidor.
404	Extraviado	No se puede encontrar el recurso en la ubicación especificada. Esta también es una respuesta común.
405	Método no permitido	El método de solicitud (GET, POST, HEAD, DELETE, PUT, TRACE, etc.) no es aplicable al recurso especificado. (Nuevo en HTTP 1.1)
406	Inaceptable	Se encontró el recurso especificado, pero su tipo MIME es incompatible con el especificado por el cliente en el encabezado Accpet (nuevo en HTTP 1.1).
407	Se requiere autenticación proxy	Similar al 401, significa que el servidor proxy primero debe autorizar al cliente. (Nuevo en HTTP 1.1)
408	Pide tiempo fuera	El cliente no ha emitido ninguna solicitud durante el tiempo de espera permitido por el servidor. El cliente puede repetir la misma solicitud más tarde. (Nuevo en HTTP 1.1)
409	Conflicto	Generalmente relacionado con solicitudes PUT. La solicitud no puede tener éxito porque entra en conflicto con el estado actual del recurso. (Nuevo en HTTP 1.1)
410	Desaparecido	El documento solicitado ya no está disponible y el servidor no sabe a qué dirección redirigir. La diferencia entre este y 404 es que devolver 407 significa que el documento abandonó permanentemente la ubicación especificada, mientras que 404 significa que el documento no está disponible por razones desconocidas. (Nuevo en HTTP 1.1)
411	Longitud requerida	El servidor no puede procesar la solicitud a menos que el cliente envíe un encabezado Content-Length. (Nuevo en HTTP 1.1)
412	Condición previa Falló	Algunas condiciones previas especificadas en el encabezado de la solicitud fallaron (nuevo en HTTP 1.1).
413	Solicitar entidad demasiado grande	El documento de destino es más grande de lo que el servidor está dispuesto a manejar actualmente. Si el servidor cree que puede manejar la solicitud más adelante, debe proporcionar un encabezado Retry-After (nuevo en HTTP 1.1).
414	Solicitar URI demasiado largo	URI demasiado larga (nueva en HTTP 1.1).
415	Tipo de medio no admitido	Para el método solicitado actualmente y el recurso solicitado, la entidad enviada en la solicitud no está en un formato admitido por el servidor, por lo que la solicitud se rechaza.
416	Rango solicitado no satisfactorio	El servidor no puede satisfacer el encabezado de rango especificado por el cliente en la solicitud. (Nuevo en HTTP 1.1)
417	Expectativa fallida	El servidor no puede cumplir con el contenido esperado especificado en el encabezado de la solicitud Expect, o el servidor es un servidor proxy y tiene evidencia clara de que el contenido de Expect no se puede cumplir en el siguiente nodo de la ruta actual.
421	Hay demasiadas conexiones desde tu dirección de Internet.	从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关 或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。
422	Unprocessable Entity	请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）
423	Locked	当前资源被锁定。（RFC 4918 WebDAV）
424	Failed Dependency	由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV）
425	Unordered Collection	在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。
426	Upgrade Required	客户端应当切换到TLS/1.0。（RFC 2817）
449	Retry With	由微软扩展，代表请求应当在执行完适当的操作后进行重试。
500	Internal Server Error	服务器遇到了意料不到的情况，不能完成客户的请求。
501	Not Implemented	服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求。
502	Bad Gateway	服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
503	Service Unavailable	服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头。
504	Gateway Timeout	由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新）
505	HTTP Version Not Supported	服务器不支持请求中所指明的HTTP版本。（HTTP 1.1新）
506	Variant Also Negotiates	由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
507	Insufficient Storage	服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)
509	Bandwidth Limit Exceeded	服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。
510	Not Extended	获取资源所需要的策略并没有没满足。（RFC 2774）

HTTP 重定向

当一个客户端访问某个 URL 的时候，由于某种原因，服务端会告诉客户端需要重新访问另一个 URL，这就是重定向。

最常见的重定向状态码就是301和302，301俗称“永久重定向”（Moved Permanently）， 302 俗称“临时重定向”（“Moved Temporarily”） 。

“Location” 字段属于响应字段，必须出现在响应报文里。但只有配合 301/302 状态码才有意义，它标记了服务器要求重定向的 URL。

301 永久重定向

很多客户端记住的是原 URL，但是这个 URL在服务端已经不用了，此时请求服务器会返回 301，浏览器看到 301，就知道原来的 URL “过时”了，就会做适当的优化。比如刷新历史记录、更新书签，下次可能就会直接用新的 URL 访问，省去了再次跳转的成本。

302 临时重定向

302 俗称“临时重定向”（“Moved Temporarily”），意思是原 URL 处于“临时 维护”状态，新的 URL是起“顶包”作用的“临时工”。

浏览器看到 302，会认为原来的 URL 仍然有效，但暂时不可用，所以只会执行简单的跳转页面，不记录新的 URL，也不会有其他的多余动作，下次访问还是用原 URL。

比如，服务器中临时维护某个 URL，就可以返回 302 状态码。

URL 格式

URI 是统一资源标识符，URL 是统一资源定位符，URL 是 URI 的一种具体实现。

URL 格式：schema://host:port/path

• schema：协议名，表示资源应该使用哪种协议来访问。如 http、https
• 在 scheme 之后，必须是三个特定的字符 ://，它把 scheme 和后面的部分分离开
• host:port 在 :// 之后，是资源所在的主机名，即主机名加端口号
• path是资源在主机上的位置路径
• 有了协议名和主机地址、端口号，再加上后面标记资源所在位置的path，浏览器就可以连接服务器访问资源了。

查询参数：schema://host:port/path?key=value&key=value

• path 后面使用一个"?“分割开来，”?"后面的就是query查询参数部分，query部分是由“&”拼接的多个key=value键值对

Al obtener imágenes, si desea especificar diferentes tamaños, el método "nombre de protocolo + nombre de host + ruta" no puede adaptarse a estos escenarios, por lo que hay una parte de "consulta" después del URI, que utiliza una "consulta" después del ruta. ?" comienza, pero no contiene "?", lo que indica requisitos adicionales de recursos.

ID de fragmento:

Es un "ancla" o "etiqueta" dentro del recurso ubicado por el URI, y el navegador puede saltar directamente a la ubicación indicada por él después de obtener el recurso.

Pero los identificadores de fragmentos solo pueden ser utilizados por clientes como navegadores y el servidor no los puede ver. En otras palabras, el navegador nunca #fragmentenviará un URI con a al servidor y el servidor nunca manejará fragmentos de recursos de esta manera.

codificación de URL

Solo se pueden usar códigos ASCII en el URI, pero ¿qué sucede si desea usar chino, japonés y otros idiomas además del inglés en el URI?

Además, en algunos URI especiales, " " y otros caracteres que funcionan como delimitadores aparecerán dentro pathy fuera, lo que provocará errores de análisis de URI. ¿Qué debemos hacer en este caso?query@&?

URI introduce un mecanismo de codificación que realiza una operación especial en conjuntos de caracteres y caracteres especiales distintos de los códigos ASCII para convertirlos en una forma que no entre en conflicto con la semántica de URI.

Las reglas de escape de URI son un poco "simples y toscas": convierten directamente códigos no ASCII o caracteres especiales en valores de bytes hexadecimales y luego agregan un " " delante de ellos %.

Por ejemplo, los espacios se escapan como " %20" y " ?" se escapan como " %3F". Los chinos, japoneses, etc. generalmente usan codificación UTF-8 y luego escapan, por ejemplo, "Galaxy" se escapará a "%E9%93%B6%E6%B2%B3".