Muestra de sesión de solicitud de rango http

91

¿Es posible mostrarme una sesión http de muestra con solicitudes de rango? Quiero decir, ¿cuáles serían los encabezados de solicitud y respuesta?

http session range sample chamal
fuente
2
Hace unos meses se publicó la nueva versión del estándar HTTP / 1.1. Tiene un RFC especial para solicitudes de rango, esto es mucho más legible que la especificación anterior, incluidos ejemplos para muchos elementos: tools.ietf.org/html/rfc7233
Thirler

Respuestas:

135

El siguiente intercambio es entre Chrome y un servidor web estático, recuperando un video MP4.

Solicitud inicial: para el video. Tenga en cuenta el Accept-Rangesencabezado de respuesta para indicar que el servidor tiene soporte de encabezado de rango:

GET /BigBuckBunny_320x180.mp4
        Cache-Control: max-age=0
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range:
        Accept: text/html,application/xhtml+xml,application/xml,*/*
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Accept-Encoding: gzip,deflate,sdch
        Accept-Charset: ISO-8859-1,utf-8,*
200 OK
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 64657027
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:24 GMT

Se detectó el encabezado de rango en la respuesta anterior: solicitud posterior con rango abierto para confirmar el soporte. La respuesta devuelve un estado y un Content-Rangeencabezado 206 para indicar los bytes presentes en el cuerpo de la respuesta:

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=0-
        Accept: */*
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 64657027
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 0-64657026/64657027

Solicitud de rango posterior para capturar el final del archivo (probablemente para capturar metadatos finales):

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=64312833-64657026
        Accept: */*
        If-Range: A023EF02BD589BC472A2D6774EAE3C58
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 344194
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 64312833-64657026/64657027

El usuario hace clic en la barra de progreso del video más allá del rango descargado; se emite una solicitud de rango para comenzar a reproducir desde la posición seleccionada:

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=1073152-64313343
        Accept: */*
        If-Range: A023EF02BD589BC472A2D6774EAE3C58
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 63240192
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 1073152-64313343/64657027
Johnstok
fuente
7
¿Es el encabezado Transfer-Encoding en blanco un artefacto de la forma en que se capturó la comunicación HTTP o hay un servidor HTTP real que genera valores en blanco para este encabezado?
swl10
7
En el primer caso, parece que el servidor devuelve 64657027 bytes de contenido. Entonces, ¿qué está sucediendo? ¿El cliente simplemente está tirando ese contenido y luego emitiendo una solicitud de rango para las partes que realmente desea? ¿O el servidor no devuelve ningún contenido porque algo en el mensaje del cliente dice que no haga eso? Si es así, ¿qué es?
Morrie
3
@ Morrie: parece que el servidor, sabiendo que él mismo admite solicitudes de rango, le dice al cliente "Acepto solicitudes de rango" a través del Accept-Ranges: bytesencabezado, pero también envía la longitud del contenido del recurso para que el cliente pueda realizar solicitudes de rango con un Unido. Hasta donde yo sé, nada en el mensaje del cliente dice que haga esto: el servidor puede elegir responder con "aquí está el recurso completo" o "Acepto solicitudes de rango", que nuevamente es la existencia del Accept-Rangesencabezado. Ese es mi entendimiento de todos modos.
Simon Whitehead
4
Pero, ¿no significa el Content-Length de 64657027 en la primera respuesta que en realidad hay tantos bytes de carga útil después del encabezado, que el cliente debe consumir porque la conexión es Keep-Alive? Me pregunto qué dice en ese mensaje de respuesta que en realidad no hay ninguna carga útil.
Morrie
1
@Morrie Keep-alive es una solicitud del cliente y el cliente no tiene ninguna obligación de seguir usando la conexión. Acabo de concluir en mi propio trabajo que, al menos para Chrome, la primera solicitud GET con rango "0-" se cancela de inmediato tan pronto como se recibe el encabezado, en lugar de usar una solicitud HEAD. Creo que es una forma de evitar problemas con cualquier servidor que no implemente correctamente el verbo HEAD.
Zoomulator