Esempio di sessione di richiesta dell'intervallo http

91

È possibile mostrarmi una sessione http di esempio con richieste di intervallo. Voglio dire, quali sarebbero le intestazioni di richiesta e risposta?

http  session  range  sample 
— chamal
fonte
2
Pochi mesi fa è stata pubblicata la nuova versione dello standard HTTP / 1.1. Ha una RFC speciale per le richieste di intervallo, molto più leggibile della vecchia specifica, inclusi esempi per molti articoli: tools.ietf.org/html/rfc7233
— Thirler

Risposte:

135

Il seguente scambio è tra Chrome e un server web statico, recuperando un video MP4.

Richiesta iniziale - per il video. Nota l' Accept-Rangesintestazione della risposta per indicare che il server ha il supporto dell'intestazione dell'intervallo:

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

Rilevata intestazione intervallo nella risposta precedente - richiesta successiva con intervallo aperto per confermare il supporto. La risposta restituisce uno stato 206 e Content-Rangeun'intestazione per indicare i byte presenti nel corpo della risposta:

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

Richiesta di intervallo successiva per acquisire la fine del file (probabilmente per acquisire i metadati finali):

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

L'utente fa clic sulla barra di avanzamento del video oltre l'intervallo scaricato: viene inviata una richiesta di intervallo per iniziare la riproduzione dalla posizione selezionata:

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
fonte
7
L'intestazione Transfer-Encoding vuota è un artefatto del modo in cui è stata acquisita la comunicazione HTTP o esiste un vero server HTTP che genera valori vuoti per questa intestazione?
— swl10
7
Nel primo caso, sembra che il server restituisca 64657027 byte di contenuto. Quindi cosa sta succedendo: il cliente sta semplicemente buttando via quel contenuto e quindi emette una richiesta di intervallo per le parti che desidera davvero? Oppure il server non restituisce alcun contenuto perché qualcosa nel messaggio del client dice di non farlo. Se è così, che cosa è?
— Morrie
3
@ Morrie - sembra che il server, sapendo che esso stesso supporta le richieste di intervallo, dica al client "Accetto le richieste di intervallo" tramite l' Accept-Ranges: bytesintestazione, ma invia anche la lunghezza del contenuto per la risorsa in modo che il client possa effettuare richieste di intervallo con un valore superiore limite. Niente nel messaggio del client dice di farlo per quanto ne so - il server può scegliere di rispondere con "qui è l'intera risorsa" o "Accetto richieste di intervallo" - che di nuovo è l'esistenza Accept-Rangesdell'intestazione. Questa è la mia comprensione comunque.
— Simon Whitehead
4
Ma la lunghezza del contenuto di 64657027 nella prima risposta non significa che ci sono effettivamente tanti byte di payload dopo l'intestazione, che il client deve consumare perché la connessione è Keep-Alive? Mi chiedo cosa dice in quel messaggio di risposta che in realtà non c'è alcun payload.
— Morrie
1
@Morrie Keep-alive è una richiesta del client e il client non ha alcun obbligo di continuare a utilizzare la connessione. Ho appena concluso nel mio lavoro che, almeno per chrome, la prima richiesta GET con intervallo "0-" viene prontamente interrotta non appena viene ricevuta l'intestazione, invece di utilizzare una richiesta HEAD. Credo che sia un modo per evitare problemi con qualsiasi server che potrebbe non implementare correttamente il verbo HEAD.
— Zoomulator
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.