Chapitre: Évolution vers un "serveur Web décent" Le a été mis à jour.
Si vous voulez en savoir plus, veuillez "aimer" ou "me suivre" dans Book ;-)
Ce qui suit est un extrait du contenu du livre.
Dans ce chapitre, déjà réalisé par tout le monde "Henachoko Web Nous allons faire évoluer le «serveur» en un «serveur Web décent».
Alors, trions exactement ce que le serveur Web que vous avez créé était un désordre.
En premier lieu, un serveur Web était un serveur qui communique selon les ** règles HTTP **. Pour le dire autrement, pour être un bon serveur web, il faut que ce soit un serveur capable de renvoyer une réponse selon les règles de HTTP **.
Cependant, votre serveur Web Henachoko ne respecte pas les règles de HTTP.
Plus précisément, regardons à nouveau la réponse (= server_send.txt) renvoyée par votre serveur.
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>
Votre serveur Web ** renverra ce contenu sous forme de réponse fixe, quel que soit le chemin de la requête. ** **
En y repensant, il semble que le format HTTP soit protégé en premier lieu. Il y a une ligne de réponse sur la première ligne, des en-têtes de la deuxième ligne et un corps après la ligne vide. À l'origine, j'ai emprunté la réponse d'Apache, donc c'est naturel
Ce n'est pas cool que le corps soit "Ça marche!" Pour toute demande de chemin, mais ce n'est pas une violation de règle. Insistons sur le fait que "nous sommes un tel service".
** Le problème est dans l'en-tête. ** **
Par exemple, selon RFC7231 7.1.1.2, l'en-tête «Date» décrit la date et l'heure auxquelles le serveur Web a envoyé la réponse. C'est censé être fait.
Cependant, il est actuellement fixe indépendamment de la date et de l'heure de génération de la réponse.
(Dans l'exemple ci-dessus, Date est fixé à 2020/10/28 7:57:45)
En outre, l'en-tête Server (RFC7231 7.4.2) contient des informations sur le programme qui a généré la réponse. C'est censé être fait, et généralement le nom du serveur Web, etc. est décrit.
Cependant, bien que nous n'ayons pas créé de serveur Web nommé Apache, il est corrigé sur Serveur: Apache / 2.4.41 (Unix).
(Ce n'est pas strictement une violation des règles, car le nom du serveur Web est libre d'être donné par le développeur du serveur, mais ce n'est pas un serveur Web "décent" pour tromper le nom du programme de quelqu'un d'autre. .)
Donc, afin d'évoluer vers un "serveur web décent", améliorons le programme afin que nous puissions organiser ces en-têtes et générer une réponse qui suit correctement les règles HTTP.
** Dans un premier temps, regardez les en-têtes qu'Apache retourne un par un pour voir si des retouches sont nécessaires. ** **
Au fait, les seuls en-têtes HTTP requis sont les en-têtes Host dans la requête, et il n'y a pas d'en-têtes requis dans la réponse.
En conséquence, cette étape supprime tout ce qui est difficile à mettre en œuvre et à apprendre.
** L'étape suivante consiste à modifier réellement le programme et à l'améliorer afin que les en-têtes appropriés puissent être inclus dans la réponse. ** **
Jetons un coup d'œil aux en-têtes inclus dans la réponse Apache, sélectionnez ceux dont vous avez besoin et vérifiez les détails des modifications. Le contenu sera un peu plus, donc si vous n'êtes pas intéressé par les détails, vous pouvez sauter.
Date
Date: Wed, 28 Oct 2020 07:57:45 GMT
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.date
Comme nous l'avons déjà vu, regardons d'abord l'en-tête Date.
«Date» représente la date et l'heure auxquelles la réponse a été générée.
Pour le moment, une date et une heure fixes ont été renvoyées, mais en Python, il est facile d'obtenir la date et l'heure en utilisant le module datetime, alors assurez-vous de renvoyer la ** date et l'heure auxquelles la réponse a été générée ** correctement.
Server
Server: Apache/2.4.41 (Unix)
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.server
Comme nous l'avons déjà vu, l'en-tête Server renvoie des informations sur le programme qui a généré la réponse.
Le contenu n'est pas spécifié, mais il est dit qu'il ne faut pas écrire d'informations trop détaillées, et il est courant de les conserver avec le nom du serveur ou le nom du système d'exploitation.
Pour le moment, il est fixé à Apache / 2.4.41 (Unix), mais donnons-lui votre propre nom d'origine.
Dans ce document, nous retournerons la version 1.0 de Henachoko Web Server, ** HenaServer / 0.1 ** pour faire court.
Veuillez vous donner un nom de votre choix.
Content-Location
Content-Location: index.html.en
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.content-location
Content-Location indique une URL alternative pour obtenir la réponse renvoyée.
Cela peut être un peu difficile à comprendre.
Dans ce cas, Chrome passe par un processus appelé négociation de contenu lors de la demande de la ressource /.
Plus précisément, Chrome est dans une requête HTTP
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
Par des en-têtes tels que "C'est le format du contenu que je peux comprendre, c'est le format de compression pris en charge, et je veux que la langue la plus soit le japonais, mais l'anglais c'est bien." Je vous le dis.
Le côté serveur génère une réponse appropriée en fonction de son contenu.
Ce travail collaboratif est appelé négociation de contenu, ce qui signifie que le contenu peut changer en fonction de la façon dont vous le demandez.
pour cette raison,
"Si vous voulez le même contenu que la réponse renvoyée cette fois, allez dans / index.html.en au lieu de/."
C'est ce que nous dit Apache.
Le serveur que nous allons créer dans ce livre ne sera pas si compliqué, donc nous ne retournerons ** pas cet en-tête **.
Vary
Vary: negotiate
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.vary
L'en-tête «Vary» est un en-tête qui contrôle si le navigateur ou le serveur intermédiaire utilise le cache. Tant que l'en-tête décrit dans cet en-tête ne change pas, cela signifie que vous pouvez utiliser le cache.
Dans ce cas, le serveur vous indique que vous pouvez réutiliser le contenu mis en cache tant qu'il n'y a pas de changement dans l'en-tête de négociation de contenu décrit précédemment.
Le contrôle du cache n'étant pas effectué dans ce document, cet en-tête ne sera ** pas retourné **.
TCN
TCN: choice
RFC: https://tools.ietf.org/html/rfc2295#section-8.5
Il s'agit d'un en-tête légèrement mineur, trouvé dans une autre RFC 2295 sur la négociation de contenu transparent.
C'est un en-tête qui raconte comment la négociation de contenu a été effectuée, mais ce sera compliqué, je vais donc omettre l'explication ici.
La négociation de contenu n'est pas effectuée dans ce document, nous ne retournerons donc ** pas cet en-tête **.
Last-Modified
Last-Modified: Thu, 29 Aug 2019 05:05:59 GMT
RFC: https://triple-underscore.github.io/RFC7232-ja.html#header.last-modified
L'en-tête Last-Modified renvoie la date et l'heure de la dernière modification du contenu.
Il est dit que cet en-tête doit être retourné si une date et une heure de dernière modification cohérentes peuvent être renvoyées.
De plus, la situation selon laquelle «la date et l'heure de la dernière modification cohérentes ne peuvent pas être renvoyées» est que le contenu est le même même si le dernier modifié est le même, ou que le contenu est le même même si le dernier modifié est différent pour les URL, etc. Il fait référence au cas où il n'y a pas de valeur Last-Modified significative.
Dans ce document, la date et l'heure de la dernière modification peuvent ou non être significatives pour chaque URL, donc pour des raisons de simplicité, cet en-tête ne sera ** pas retourné **.
ETag
ETag: "2d-5913a76187bc0"
RFC: https://triple-underscore.github.io/RFC7232-ja.html#header.etag
L'en-tête «ETag» est un identifiant qui indique la version particulière de la ressource qui générera la réponse. En d'autres termes, si la ressource est mise à jour de quelque manière que ce soit, on s'attend à ce que l'ETag ait également une valeur différente. Dans de nombreux cas, les valeurs de hachage des fichiers et du contenu sont utilisées.
Ceci est également utilisé pour le contrôle du cache des navigateurs et des serveurs intermédiaires, mais comme le contrôle du cache n'est pas traité dans ce document, cet en-tête ne sera ** pas retourné **.
Accept-Ranges
Accept-Ranges: bytes
RFC: https://triple-underscore.github.io/RFC7233-ja.html#header.accept-ranges
L'en-tête Accept-Ranges est un en-tête qui indique qu'il correspond à une" demande partielle pour une ressource "appelée" Range Requests ".
«Requêtes de plage» est une fonction qui vous permet d'effectuer des téléchargements fractionnés lors du téléchargement de fichiers volumineux.
Ce document ne prend pas en charge les «Requêtes de plage», donc cet en-tête ne sera ** pas retourné **.
Content-Length
Content-Length: 45
RFC: https://triple-underscore.github.io/RFC7230-ja.html#header.content-length
L'en-tête Content-Length renvoie une valeur décimale qui indique le nombre d'octets dans le corps de la réponse.
Cela signifie que le serveur doit être renvoyé, à quelques exceptions près.
Il n'est pas difficile d'obtenir le nombre d'octets en python, donc je vais m'assurer de ** renvoyer le nombre d'octets dans le corps **.
Keep-Alive
Keep-Alive: timeout=5, max=100
RFC: https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#keep-alive
L'en-tête Keep-Alive renvoie des informations sur la durée pendant laquelle une connexion peut être réutilisée pour la réutilisation de connexion décrite ci-dessous.
Cet en-tête a été soumis en tant que projet de RFC (spécification expérimentale) et est pris en charge par presque tous les navigateurs modernes, mais n'a pas encore été incorporé en tant que spécification standard RFC formelle.
Cet en-tête n'est ** pas retourné ** car ce document n'implémente pas la réutilisation des connexions.
Connection
Connection: Keep-Alive
L'en-tête Connection renvoie si la connexion TCP une fois établie peut être réutilisée dans la requête suivante.
Les connexions TCP prennent un certain temps à s'établir et la réutilisation des connexions TCP est connue pour être efficace pour optimiser la vitesse d'affichage.
La fonction de réutilisation de connexion sort du cadre de ce document et ne sera pas implémentée.
Cependant, dans HTTP / 1.1, la communication est censée réutiliser la connexion par défaut, et ** Les serveurs qui ne prennent pas en charge la réutilisation de la connexion doivent renvoyer Connection: Close. Puisque c'est le cas, je reviendrai sur ceci dans ce livre. ** **
Content-Type
Content-Type: text/html
RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.content-type
L'en-tête Content-Type renvoie le format du corps de la réponse.
La valeur qui peut être utilisée est une valeur appelée «Type MIME».
Etc.
Si vous souhaitez consulter la liste, ce site vous sera utile.
Si vous omettez cet en-tête, il sera traité comme un "fichier non identifié" et risque de ne pas s'afficher sur l'écran du navigateur, renvoyez donc celui qui correspond correctement au contenu.
Dans ce livre, seul HTML sera renvoyé comme corps à l'étape suivante, donc ** Premièrement, nous retournerons text / html de manière fixe. ** **
De plus, si vous décidez de renvoyer un corps autre que HTML plus tard, améliorons-le afin que diverses valeurs puissent être renvoyées.
Chapitre: Évolution vers un "serveur Web décent"
Recommended Posts