Interpretación de la longitud del contenido en el protocolo HTTP

En el protocolo HTTP, hay una interpretación detallada de Content-Length. Content-Length se utiliza para describir la longitud de transferencia de la entidad de mensaje HTTP. En el protocolo HTTP, la longitud de la entidad de mensaje y la longitud de transmisión de la entidad de mensaje son diferentes. Por ejemplo, en compresión gzip, la longitud de la entidad de mensaje es la longitud antes de la compresión, y la longitud de transmisión de la entidad de mensaje es la longitud después de la compresión gzip. En la interacción HTTP específica, ¿cómo obtiene el cliente la longitud del mensaje, principalmente en base a las siguientes reglas? Si la respuesta es 1xx, 204, 304 o solicitud principal, el contenido de la entidad del mensaje se ignora directamente. Si hay Transfer-Encoding, el método en Transfer-Encoding se usa primero para encontrar la longitud correspondiente. Por ejemplo, el modo Chunked. " Si hay Content-Length en la cabecera, entonces Content-Length representa tanto la longitud de la entidad como la longitud de la transmisión. Si la longitud de la entidad y la longitud de la transferencia no son iguales (por ejemplo, la codificación de la transferencia está establecida), no se puede establecer la longitud del contenido. Si se establece Transfer-Encoding, Content-Length se ignorará. La ventaja de la traducción de esta oración es, de hecho, el punto clave es: con la codificación de transferencia, no puede haber longitud de contenido. Transmisión de alcance. No preste atención, no lea en detalle :) La longitud de la conexión se puede determinar cerrando la conexión a través del servidor.
(El solicitante no puede indicar el final del cuerpo del mensaje de solicitud cerrando la conexión, ya que esto le dará al servidor la posibilidad de continuar respondiendo). Esta situación corresponde principalmente a una conexión corta, es decir, un modo de no mantener la vida. HTTP 1.1 debe soportar el modo chunk. Porque cuando la longitud del mensaje es incierta, esto puede ser manejado por el mecanismo de trozos. En el encabezado que contiene el contenido del mensaje, si hay un campo de longitud de contenido, el valor correspondiente al campo debe coincidir con la longitud del asunto del mensaje. "La longitud de la entidad de un mensaje es la longitud del cuerpo del mensaje antes de que se hayan aplicado las codificaciones de transferencia", es decir, no hay longitud de contenido para los fragmentos.

De hecho, los siguientes artículos casi pueden ignorarse, y lo siguiente se resume brevemente de la siguiente manera: 1. Si Content-Length existe y es válido, debe ser exactamente igual a la longitud de transmisión del contenido del mensaje.
(Después de la prueba, si es demasiado corto, se truncará. Si es demasiado largo, causará un tiempo de espera). 2. Si hay Transfer-Encoding (el enfoque está fragmentado), no puede haber Content-Length en el encabezado y se ignorará. 3. Si se usa una conexión corta, la longitud de la conexión del mensaje puede ser determinada directamente por el servidor que cierra la conexión.
(Esto es fácil de entender) Combinado con otras características del protocolo HTTP, por ejemplo, antes de que Http1.1 no admita mantenerlo vivo. Luego, puede sacar las siguientes conclusiones: 1. En Http 1.0 y versiones anteriores, el campo de longitud del contenido es opcional. 2. En http1.1 y versiones posteriores. Si se mantiene vivo, entonces la longitud del contenido y el fragmento deben ser dos. Si no se mantiene vivo, es lo mismo que http1.0. La longitud del contenido es opcional.