Beispiel einer http-Bereichsanforderungssitzung

Ist es möglich, mir eine Beispiel-http-Sitzung mit Bereichsanforderungen anzuzeigen? Ich meine, was wären die Anforderungs- und Antwortheader?

— Chamal
quelle

Vor einigen Monaten wurde die neue Version des HTTP / 1.1-Standards veröffentlicht. Es hat einen speziellen RFC für Bereichsanforderungen, dieser ist viel besser lesbar als die alte Spezifikation, einschließlich Beispielen für viele Elemente: tools.ietf.org/html/rfc7233

— Thirler

134

Der folgende Austausch findet zwischen Chrome und einem statischen Webserver statt und ruft ein MP4-Video ab.

Erste Anfrage - für das Video. Beachten Sie den Accept-RangesAntwortheader, um anzugeben, dass der Server Range Header unterstützt:

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

Bereichskopf in der vorherigen Antwort erkannt - nachfolgende Anforderung mit offenem Bereich zur Bestätigung der Unterstützung. Die Antwort gibt einen 206-Status und einen Content-RangeHeader zurück, um die im Antworttext vorhandenen Bytes anzugeben:

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

Nachfolgende Bereichsanforderung zum Erfassen des Dateiende (wahrscheinlich zum Erfassen nachfolgender Metadaten):

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

Der Benutzer klickt in der Video-Fortschrittsleiste über den heruntergeladenen Bereich hinaus. Es wird eine Bereichsanforderung ausgegeben, um die Wiedergabe an der ausgewählten Position zu starten:

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
quelle

Ist der leere Transfer-Encoding-Header ein Artefakt der Art und Weise, wie die HTTP-Kommunikation erfasst wurde, oder gibt es einen echten HTTP-Server, der leere Werte für diesen Header generiert?

— swl10

Im ersten Fall sieht es so aus, als würde der Server 64657027 Byte Inhalt zurückgeben. Also, was passiert - wirft der Kunde diesen Inhalt einfach weg und gibt anschließend eine Bereichsanfrage für die Teile aus, die er wirklich möchte? Oder gibt der Server keinen Inhalt zurück, weil in der Nachricht des Clients angegeben ist, dass dies nicht der Fall ist. Wenn ja, was ist das?

— Morrie

@Morrie - Es scheint, als würde der Server, der weiß, dass er selbst Bereichsanforderungen unterstützt, dem Client über den Accept-Ranges: bytesHeader "Ich akzeptiere Bereichsanforderungen" mitteilen, aber er sendet auch die Inhaltslänge für die Ressource herunter, damit der Client Bereichsanforderungen mit einem oberen Wert stellen kann gebunden. Soweit mir bekannt ist, sagt dies in der Client-Nachricht nichts aus. Der Server kann wählen, ob er mit "Hier ist die gesamte Ressource" oder "Ich akzeptiere Bereichsanforderungen" antworten möchte. Dies ist wiederum das Vorhandensein des Accept-RangesHeaders. Das verstehe ich sowieso.

— Simon Whitehead

Aber bedeutet die Inhaltslänge von 64657027 in der ersten Antwort nicht, dass dem Header tatsächlich so viele Bytes an Nutzdaten folgen, die der Client verbrauchen muss, weil die Verbindung Keep-Alive ist? Ich frage mich, was in dieser Antwortnachricht steht, dass es tatsächlich keine Nutzlast gibt.

— Morrie

@Morrie Keep-Alive ist eine Anfrage des Kunden und der Kunde ist nicht verpflichtet, die Verbindung weiter zu nutzen. Ich bin gerade in meiner eigenen Arbeit zu dem Schluss gekommen, dass zumindest für Chrome die erste GET-Anforderung mit dem Bereich "0-" sofort abgebrochen wird, sobald der Header empfangen wird, anstatt eine HEAD-Anforderung zu verwenden. Ich glaube, dass dies eine Möglichkeit ist, Probleme mit Servern zu vermeiden, die das HEAD-Verb möglicherweise nicht korrekt implementieren.

— Zoomulator