Exemple de session de demande de plage http

91

Est-il possible de me montrer un exemple de session http avec des demandes de plage. Je veux dire quels seraient les en-têtes de demande et de réponse?

http session range sample Chamal
la source
2
Il y a quelques mois, la nouvelle version du standard HTTP / 1.1 a été publiée. Il a une RFC spéciale pour les demandes de plage, c'est beaucoup plus lisible que l'ancienne spécification, y compris des exemples pour de nombreux éléments: tools.ietf.org/html/rfc7233
Thirler

Réponses:

135

L'échange suivant est entre Chrome et un serveur Web statique, récupérant une vidéo MP4.

Demande initiale - pour la vidéo. Notez l'en- Accept-Rangestête de réponse pour indiquer que le serveur prend en charge l'en-tête de plage:

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

En-tête de plage détecté dans la réponse précédente - demande ultérieure avec plage ouverte pour confirmer la prise en charge. La réponse renvoie un état et un en- Content-Rangetête 206 pour indiquer les octets présents dans le corps de la réponse:

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

Demande de plage ultérieure pour capturer la fin du fichier (probablement pour capturer les métadonnées de fin):

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'utilisateur clique dans la barre de progression de la vidéo au-delà de la plage téléchargée - une demande de plage est émise pour commencer la lecture à partir de la position sélectionnée:

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
la source
7
L'en-tête Transfer-Encoding vierge est-il un artefact de la façon dont la communication HTTP a été capturée ou y a-t-il un vrai serveur HTTP qui génère des valeurs vides pour cet en-tête?
swl10
7
Dans le premier cas, il semble que le serveur renvoie 64657027 octets de contenu. Alors que se passe-t-il - le client jette-t-il simplement ce contenu, puis émet-il ensuite une demande de plage pour les pièces qu'il souhaite vraiment? Ou est-ce que le serveur ne renvoie aucun contenu parce que quelque chose dans le message du client dit de ne pas le faire. Si oui, qu'est-ce que c'est?
Morrie
3
@Morrie - il semble que le serveur, sachant qu'il prend lui-même en charge les requêtes de plage, dit au client "J'accepte les requêtes de plage" via l'en- Accept-Ranges: bytestête, mais il envoie également la longueur du contenu de la ressource afin que le client puisse faire des requêtes de plage avec un supérieur lié. Rien dans le message client n'indique de faire cela pour autant que je sache - le serveur peut choisir de répondre par "voici la ressource entière" ou "J'accepte les demandes de plage" - ce qui est là encore l'existence de l'en- Accept-Rangestête. C'est ma compréhension de toute façon.
Simon Whitehead
4
Mais le Content-Length de 64657027 dans la première réponse ne signifie-t-il pas qu'il y a en fait autant d'octets de charge utile après l'en-tête, que le client doit consommer car la connexion est Keep-Alive? Je me demande ce que dit ce message de réponse qu'il n'y a en fait aucune charge utile.
Morrie
1
@Morrie Keep-alive est une demande du client et le client n'a aucune obligation de continuer à utiliser la connexion. Je viens de conclure dans mon propre travail que, au moins pour chrome, la première requête GET avec la plage "0-" est rapidement abandonnée dès que l'en-tête est reçu, au lieu d'utiliser une requête HEAD. Je pense que c'est un moyen d'éviter les problèmes avec tout serveur qui ne peut pas implémenter correctement le verbe HEAD.
Zoomulator