headers - Encabezado del rango HTTP
http headers firefox (3)
Estaba leyendo http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 e intentando descubrir cómo continuar la descarga de un archivo.
Por ejemplo, supongamos que un archivo tiene una longitud de 100 bytes y tengo todos los 100 bytes. Sin embargo, no sé cuál debería ser el tamaño de archivo esperado, entonces solicito el archivo y especifico un encabezado de rango que se ve así:
Range: bytes=100-
¿Es esta una solicitud de Rango válida?
Como sugirió Wrikken , es una solicitud válida. También es bastante común cuando el cliente solicita medios o reanuda una descarga.
Un cliente a menudo probará para ver si el servidor maneja las solicitudes a distancia además de solo buscar una respuesta de Accept-Ranges . Chrome siempre envía un Range: bytes=0- con su primera solicitud GET para un video, por lo que es algo que no puede descartar.
Cada vez que un cliente incluye Range: en su solicitud, incluso si está mal formado, está esperando una respuesta de contenido parcial (206). Cuando busca avanzar durante la reproducción de video HTML5, el navegador solo solicita el punto de inicio. Por ejemplo:
Range: bytes=3744-
Entonces, para que el cliente reproduzca el video correctamente, su servidor debe ser capaz de manejar estas solicitudes de rango incompletas.
Puede manejar el tipo de ''rango'' que especificó en su pregunta de dos maneras:
En primer lugar, puede responder con el punto de inicio solicitado en la respuesta, luego la longitud total del archivo menos uno (el rango de bytes solicitados tiene índice cero). Por ejemplo:
Solicitud:
GET /BigBuckBunny_320x180.mp4
Range: bytes=100-
Respuesta:
206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/64656927
En segundo lugar, podría responder con el punto de partida dado en la solicitud y una longitud de archivo abierta (tamaño). Esto es para webcasts u otros medios donde la longitud total es desconocida. Por ejemplo:
Solicitud:
GET /BigBuckBunny_320x180.mp4
Range: bytes=100-
Respuesta:
206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/*
Consejos:
Siempre debe responder con la longitud del contenido incluida con el rango. Si el rango está completo, de principio a fin, la duración del contenido es simplemente la diferencia:
Solicitud: Rango: bytes = 500-1000
Respuesta: rango de contenido: bytes 500-1000 / 123456
Recuerde que el rango tiene índice cero, por lo que Range: bytes=0-999 realidad está solicitando 1000 bytes, no 999, entonces responda con algo como:
Content-Length: 1000
Content-Range: bytes 0-999/123456
O:
Content-Length: 1000
Content-Range: bytes 0-999/*
Pero, si es posible, evite este último método porque algunos reproductores de medios intentan calcular la duración del tamaño del archivo. Si su solicitud es para contenido multimedia, que es mi corazonada, entonces debe incluir su duración en la respuesta. Esto se hace con el siguiente formato:
X-Content-Duration: 63.23
Este debe ser un punto flotante. A diferencia de Content-Length , este valor no tiene que ser preciso. Se usa para ayudar al jugador a buscar el video. Si está transmitiendo un webcast y solo tiene una idea general de cuánto tiempo será, es mejor incluir su duración estimada en lugar de ignorarla por completo. Entonces, para una transmisión web de dos horas, podría incluir algo como:
X-Content-Duration: 7200.00
Con algunos tipos de medios, como webm, también debe incluir el tipo de contenido, como:
Content-Type: video/webm
Todos estos son necesarios para que los medios se reproduzcan correctamente, especialmente en HTML5. Si no le da una duración, el jugador puede intentar calcular la duración (para permitir la búsqueda) de su tamaño de archivo, pero esto no será preciso. Esto está bien, y es necesario para webcasts o transmisión en vivo, pero no es ideal para la reproducción de archivos de video. Puede extraer la duración usando software como FFMPEG y guardarlo en una base de datos o incluso en el nombre del archivo.
X-Content-Duration se está eliminando gradualmente a favor de Content-Duration , así que también incluiría eso. Una respuesta básica a una solicitud "0-" incluiría al menos lo siguiente:
HTTP/1.1 206 Partial Content
Date: Sun, 08 May 2013 06:37:54 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 3980
Content-Range: bytes 0-3979/3980
Content-Type: video/webm
X-Content-Duration: 2054.53
Content-Duration: 2054.53
Un punto más: Chrome siempre comienza su primera solicitud de video con lo siguiente:
Range: bytes=0-
Algunos servidores enviarán una respuesta regular de 200 como respuesta, que acepta (pero con opciones de reproducción limitadas), pero intenta enviar un 206 para mostrar que el servidor maneja los rangos. RFC 2616 dice que es aceptable ignorar los encabezados de rango.
Contrariamente a la respuesta de Mark Novakowski, que por alguna razón ha sido votado por muchos, sí, es una solicitud válida y satisfactoria.
De hecho, el estándar, como señaló Wrikken, es solo un ejemplo. En la práctica, Firefox responde a las solicitudes como se esperaba (con un código 206), y esto es exactamente lo que uso para implementar la descarga progresiva, es decir, obtener la cola de un archivo de registro largo que crece en tiempo real con el sondeo.
Es una solicitud sintácticamente válida, pero no una solicitud satisfactoria. Si miras más en esa sección, ves:
Si un conjunto de rango de bytes válido sintácticamente incluye al menos una especificación de rango de bytes cuya primera posición de byte es menor que la longitud actual de la entidad-cuerpo, o al menos un sufijo-rango-byte-especificación con un no - sufijo cero-length, luego el byte-range-set es satisfactorio. De lo contrario, el conjunto de rango de bytes no es satisfactorio. Si el conjunto de rango de bytes no es satisfactorio, el servidor DEBERÍA devolver una respuesta con un estado de 416 (el rango solicitado no es satisfactorio) . De lo contrario, el servidor DEBERÍA devolver una respuesta con un estado de 206 (Contenido parcial) que contenga los rangos satisfactorios de la entidad-cuerpo.
Así que creo que en su ejemplo, el servidor debe devolver un 416 ya que no es un rango de bytes válido para ese archivo.