Kapitel: Entwicklung zu einem "anständigen Webserver" Das wurde aktualisiert.
Wenn Sie mehr lesen möchten, "mögen" oder "folgen Sie mir" in Buch ;-)
Das Folgende ist ein Auszug aus dem Inhalt des Buches.
In diesem Kapitel bereits von allen erstellt "Henachoko Web Wir werden "Server" zu "anständigen Webservern" entwickeln.
Lassen Sie uns also herausfinden, was genau der von Ihnen erstellte Webserver umständlich war.
Erstens war ein Webserver ein Server, der gemäß ** HTTP-Regeln ** kommuniziert. Um es anders herum auszudrücken: Um ein guter Webserver zu sein, muss es ein Server sein, der eine Antwort gemäß den Regeln von HTTP ** zurückgeben kann.
Ihr Henachoko-Webserver hält sich jedoch nicht an die HTTP-Regeln.
Schauen wir uns noch einmal die Antwort (= server_send.txt) an, die von Ihrem Server zurückgegeben wurde.
server_send.txt
HTTP/1.1 200 OK
Date: Wed, 28 Oct 2020 07:57:45 GMT
Server: Apache/2.4.41 (Unix)
Content-Location: index.html.en
Vary: negotiate
TCN: choice
Last-Modified: Thu, 29 Aug 2019 05:05:59 GMT
ETag: "2d-5913a76187bc0"
Accept-Ranges: bytes
Content-Length: 45
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
<html><body><h1>It works!</h1></body></html>
Ihr Webserver ** gibt diesen Inhalt als feste Antwort zurück, unabhängig davon, auf welchem Pfad die Anforderung eingeht. ** ** **
Bei erneuter Betrachtung scheint das HTTP-Format in erster Linie geschützt zu sein. In der ersten Zeile befindet sich eine Antwortzeile, in der zweiten Zeile einige Überschriften und nach der Leerzeile ein Text. Ursprünglich habe ich mir Apaches Antwort geliehen, das ist also natürlich
Es ist nicht cool, dass der Körper "Es funktioniert!" Ist. Für jede Pfadanforderung, aber es ist keine Regelverletzung. Lassen Sie uns darauf bestehen, dass "wir so ein Dienst sind".
** Das Problem liegt in der Kopfzeile. ** ** **
Beispielsweise beschreibt der Header "Datum" gemäß RFC7231 7.1.1.2 das Datum und die Uhrzeit, zu der der Webserver die Antwort gesendet hat. Es soll gemacht werden. Es ist jedoch derzeit unabhängig vom Datum und der Uhrzeit der Antwortgenerierung festgelegt. (Im obigen Beispiel ist "Datum" auf "2020/10/28 7:57:45" festgelegt.)
Außerdem enthält der Server-Header (RFC7231 7.4.2) Informationen zu dem Programm, das die Antwort generiert hat. Es soll gemacht werden, und im Allgemeinen wird der Name des Webservers usw. beschrieben. Obwohl wir keinen Webserver mit dem Namen "Apache" erstellt haben, ist dieser auf "Server: Apache / 2.4.41 (Unix)" behoben.
(Es handelt sich nicht ausschließlich um einen Regelverstoß, da der Name des Webservers vom Serverentwickler frei angegeben werden kann, aber es ist kein "anständiger" Webserver, um den Programmnamen eines anderen zu täuschen. .)
Um uns zu einem "anständigen Webserver" zu entwickeln, verbessern wir das Programm, damit wir diese Header anordnen und eine Antwort generieren können, die den HTTP-Regeln ordnungsgemäß entspricht.
** Sehen Sie sich als ersten Schritt die Header an, die Apache nacheinander zurückgibt, um festzustellen, ob Nacharbeiten erforderlich sind. ** ** **
Übrigens sind die einzigen erforderlichen HTTP-Header die Host-Header in der Anfrage, und die Antwort enthält keine erforderlichen Header. Infolgedessen entfernt dieser Schritt alles, was schwer zu implementieren und zu lernen ist.
** Der nächste Schritt besteht darin, das Programm tatsächlich zu ändern und zu verbessern, damit die entsprechenden Header in die Antwort aufgenommen werden können. ** ** **
Schauen wir uns die in der Apache-Antwort enthaltenen Header der Reihe nach an, wählen Sie die erforderlichen aus und überprüfen Sie den Inhalt der Überarbeitung. Der Inhalt wird etwas umfangreicher sein. Wenn Sie also nicht an den Details interessiert sind, können Sie ihn überspringen.
Date
Date: Wed, 28 Oct 2020 07:57:45 GMT
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.date
Wie wir bereits gesehen haben, schauen wir uns zuerst den Date-Header an.
"Datum" gibt das Datum und die Uhrzeit an, zu der die Antwort generiert wurde.
Momentan werden ein festes Datum und eine feste Uhrzeit zurückgegeben. In Python ist es jedoch einfach, Datum und Uhrzeit mithilfe des Moduls "Datum / Uhrzeit" abzurufen. Geben Sie also Datum und Uhrzeit zurück, zu denen die Antwort ordnungsgemäß generiert wurde **.
Server
Server: Apache/2.4.41 (Unix)
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.server
Wie wir bereits gesehen haben, gibt der Server-Header Informationen über das Programm zurück, das die Antwort generiert hat.
Der Inhalt ist nicht angegeben, aber es wird gesagt, dass Sie keine zu detaillierten Informationen schreiben sollten, und es ist üblich, ihn auf den Servernamen oder den Betriebssystemnamen zu beschränken.
Im Moment ist es auf "Apache / 2.4.41 (Unix)" festgelegt, aber geben wir ihm Ihren eigenen ursprünglichen Namen.
In diesem Dokument geben wir Version 0.1 von Henachoko Web Server zurück, kurz HenaServer / 0.1 **.
Bitte geben Sie sich einen Namen Ihrer Wahl.
Content-Location
Content-Location: index.html.en
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.content-location
Content-Location gibt eine alternative URL an, um die zurückgegebene Antwort zu erhalten.
Dies kann etwas schwer zu verstehen sein.
In diesem Fall durchläuft Chrome beim Anfordern der Ressource / einen Prozess namens Inhaltsverhandlung.
Insbesondere befindet sich Chrome in einer HTTP-Anforderung
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7
Durch Überschriften wie "Dies ist das Format des Inhalts, das ich verstehen kann, dies ist das unterstützte Komprimierungsformat, und ich möchte, dass die Sprache am meisten Japanisch ist, aber Englisch ist in Ordnung." Das sage ich dir.
Die Serverseite generiert eine entsprechende Antwort entsprechend ihrem Inhalt.
Diese Zusammenarbeit wird als Inhaltsverhandlung bezeichnet. Dies bedeutet, dass sich der Inhalt je nach Anforderung ändern kann.
aus diesem Grund, "Wenn Sie denselben Inhalt wie die Antwort haben möchten, die dieses Mal zurückgegeben wurde, gehen Sie zu" / index.html.en "anstelle von" / "." Das sagt uns Apache.
Der Server, den wir in diesem Buch erstellen, wird nicht so kompliziert sein, daher werden wir diesen Header nicht zurückgeben.
Vary
Vary: negotiate
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.vary
Der "Vary" -Header ist ein Header, der steuert, ob der Browser oder der Zwischenserver den Cache verwendet. Solange sich der in diesem Header beschriebene Header nicht ändert, bedeutet dies, dass Sie den Cache verwenden können.
In diesem Fall teilt Ihnen der Server mit, dass Sie den zwischengespeicherten Inhalt wiederverwenden können, solange sich der zuvor beschriebene Header für die Inhaltsverhandlung nicht ändert.
Da in diesem Dokument keine Cache-Steuerung durchgeführt wird, wird dieser Header ** nicht zurückgegeben **.
TCN
TCN: choice
RFC: https://tools.ietf.org/html/rfc2295#section-8.5
Dies ist ein etwas kleinerer Header, der in einem anderen RFC 2295 über die Verhandlung transparenter Inhalte enthalten ist.
Es ist ein Header, der angibt, wie die Inhaltsverhandlung durchgeführt wurde, aber es wird kompliziert, daher werde ich die Erklärung hier weglassen.
Die Inhaltsverhandlung wird in diesem Dokument nicht durchgeführt, daher werden wir diesen Header nicht zurückgeben.
Last-Modified
Last-Modified: Thu, 29 Aug 2019 05:05:59 GMT
RFC: https://triple-underscore.github.io/RFC7232-ja.html#header.last-modified
Der Header "Zuletzt geändert" gibt das Datum und die Uhrzeit zurück, zu der der Inhalt zuletzt geändert wurde. Es wird gesagt, dass dieser Header zurückgegeben werden sollte, wenn ein konsistentes Datum und eine Uhrzeit der letzten Änderung zurückgegeben werden können.
Darüber hinaus besteht die Situation, dass "konsistentes Datum und Uhrzeit der letzten Änderung nicht zurückgegeben werden können" darin, dass der Inhalt derselbe ist, obwohl der zuletzt geänderte Inhalt derselbe ist, oder dass der Inhalt derselbe ist, obwohl der zuletzt geänderte in der URL usw. unterschiedlich ist, wobei der Inhalt für jede Anforderung unterschiedlich ist. Es bezieht sich auf den Fall, in dem es keinen aussagekräftigen Wert für die letzte Änderung gibt.
In diesem Dokument kann das Datum und die Uhrzeit der letzten Änderung für jede URL von Bedeutung sein oder auch nicht. Der Einfachheit halber wird dieser Header ** nicht zurückgegeben **.
ETag
ETag: "2d-5913a76187bc0"
RFC: https://triple-underscore.github.io/RFC7232-ja.html#header.etag
Der ETag-Header ist eine Kennung, die die bestimmte Version der Ressource angibt, die die Antwort generiert. Mit anderen Worten, wenn die Ressource in irgendeiner Weise aktualisiert wird, wird erwartet, dass der ETag auch einen anderen Wert hat. In vielen Fällen werden Hashwerte von Dateien und Inhalten verwendet.
Dies wird auch für die Cache-Steuerung von Browsern und Zwischenservern verwendet. Da die Cache-Steuerung in diesem Dokument jedoch nicht behandelt wird, wird dieser Header ** nicht zurückgegeben **.
Accept-Ranges
Accept-Ranges: bytes
RFC: https://triple-underscore.github.io/RFC7233-ja.html#header.accept-ranges
Der "Accept-Ranges" -Header ist ein Header, der angibt, dass er einer "Teilanforderung für eine Ressource" mit dem Namen "Range Requests" entspricht.
Range Requests ist eine Funktion, mit der Sie beim Herunterladen großer Dateien geteilte Downloads durchführen können.
Dieses Dokument unterstützt keine "Bereichsanforderungen", daher wird dieser Header ** nicht zurückgegeben **.
Content-Length
Content-Length: 45
RFC: https://triple-underscore.github.io/RFC7230-ja.html#header.content-length
Der Header "Content-Length" gibt einen Dezimalwert zurück, der die Anzahl der Bytes im Antworttext angibt.
Dies bedeutet, dass der Server mit einigen Ausnahmen zurückgegeben werden sollte.
Es ist nicht schwierig, die Anzahl der Bytes in Python zu ermitteln, daher werde ich sicherstellen, dass ** die Anzahl der Bytes im Body zurückgegeben wird **.
Keep-Alive
Keep-Alive: timeout=5, max=100
RFC: https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#keep-alive
Der Header "Keep-Alive" gibt Informationen darüber zurück, wie lange eine Verbindung für die unten beschriebene Wiederverwendung der Verbindung wiederverwendet werden kann.
Dieser Header wurde als Entwurf einer RFC (experimentelle Spezifikation) eingereicht und wird von fast allen modernen Browsern unterstützt, wurde jedoch noch nicht als formale RFC-Standardspezifikation aufgenommen.
Dieser Header wird ** nicht zurückgegeben **, da in diesem Dokument keine Wiederverwendung von Verbindungen implementiert wird.
Connection
Connection: Keep-Alive
Der Header "Verbindung" gibt zurück, ob die einmal hergestellte TCP-Verbindung bei der nächsten Anforderung wiederverwendet werden kann.
Das Herstellen von TCP-Verbindungen dauert einige Zeit, und die Wiederverwendung von TCP-Verbindungen ist bekanntermaßen bei der Optimierung der Anzeigegeschwindigkeit wirksam.
Die Funktion zur Wiederverwendung von Verbindungen liegt außerhalb des Geltungsbereichs dieses Dokuments und wird nicht implementiert.
In "HTTP / 1.1" soll die Kommunikation die Verbindung standardmäßig wiederverwenden, und ** Server, die die Wiederverwendung der Verbindung nicht unterstützen, müssen "Verbindung: Schließen" zurückgeben. Da es so ist, werde ich dies in diesem Buch zurückgeben. ** ** **
Content-Type
Content-Type: text/html
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.content-type
Der Header "Content-Type" gibt das Format des Antwortkörpers zurück. Der Wert, der verwendet werden kann, ist ein Wert namens "MIME-Type".
Und so weiter.
Wenn Sie die Liste überprüfen möchten, ist diese Site hilfreich.
Wenn Sie diesen Header weglassen, wird er als "nicht identifizierte Datei" behandelt und möglicherweise nicht auf dem Browserbildschirm angezeigt. Geben Sie daher die Datei zurück, die dem Inhalt ordnungsgemäß entspricht.
In diesem Buch wird im nächsten Schritt nur "HTML" als Text zurückgegeben. ** Zuerst geben wir "text / html" fest zurück. ** ** ** Wenn Sie später einen anderen Text als "HTML" zurückgeben möchten, verbessern wir ihn, damit verschiedene Werte zurückgegeben werden können.
Kapitel: Entwicklung zu einem "anständigen Webserver"
Recommended Posts