More than 3 years have passed since last update.

本を更新しました: 「まともなWebサーバー」へ進化する

Posted at 2020-11-09

本を更新しました

チャプター: 「まともなWebサーバー」へ進化するを更新しました。

続きを読みたい方は、ぜひBookの「いいね」か「筆者フォロー」をお願いします ;-)

以下、書籍の内容の抜粋です。

まともなWebサーバーになるためには？

本章では、既に皆さんに作っていただいた「へなちょこWebサーバー」を、「まともなWebサーバー」へ進化させていきます。

そこで、皆さんに作っていただいたWebサーバーが具体的何がへなちょこだったのか整理しておきましょう。

そもそもWebサーバーとは、HTTPのルールにしたがって通信を行うサーバーのことでした。
逆に言うと、いっぱしのWebサーバーになるためには、HTTPのルールに従ってレスポンスを返せるサーバーでなくてはありません。

しかし、皆さんのへなちょこWebサーバーは、HTTPのルールにしっかりと従っているとは言えません。

具体的に皆さんのサーバーが返しているレスポンス(= server_send.txt)を再度見てみましょう。

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>

みなさんのWebサーバーは、いつどんなpathにリクエストが来ても、固定でこの内容をレスポンスとして返しています。

改めて見て見ると、そもそもHTTPのフォーマットを守れているかと言うと、しっかりと守れていそうです。
1行目にレスポンスラインがあり、2行目からいくつかのヘッダーがあり、空行の後にボディがあります。
もともとApacheのレスポンスを拝借したので、これは当たり前ですね

どんなpathへのリクエストであってもボディが「It works!」なのは、イケてはいませんがルール違反というほどではありません。
「うちはそういうサービスなのだ」と言い張ることにしましょう。

問題は、ヘッダーにあります。

例えばRFC7231 7.1.1.2 によると、DateヘッダーはWebサーバーがレスポンスを発信した日時を記載しなければならないことになっています。
しかし、現在はレスポンス生成日時に関係なく固定になってしまっています。
（上記例だとDateは2020/10/28 7:57:45固定）

また、Serverヘッダー(RFC7231 7.4.2 )は、レスポンスを生成したプログラムに関する情報を記載することになっており、一般的にWebサーバーの名前などが記載されます。
しかし、私達が作ったのはApacheという名前のWebサーバーではないのに、Server: Apache/2.4.41 (Unix)で固定になってしまっています。

（Webサーバー名はサーバーの開発者が自由につけていいことになっているので、厳密にはルール違反ではありませんが、他人のプログラム名を騙るのは「まともな」Webサーバーとは言えないでしょう。）

というわけで、「まともなWebサーバー」に進化するために、これらのヘッダーを整えてHTTPのルールにきちんと従ったレスポンスを自力で生成できるようにプログラムを改良していきましょう。

最初のステップとして、Apacheが返しているヘッダーを1つずつ見ていって、手直しが必要かどうか確認していきます。

ちなみに、HTTPヘッダーのうち必須とされているものは、リクエストにおけるHostヘッダーのみであり、レスポンスには必須ヘッダーは存在しません。
そのため、実装や学習に手間のかかるものはこのステップで取り除いてしまいます。

次のステップとして、プログラムを実際に修正し、適切なヘッダーをレスポンスに含めることができるように改良していきます。

Apacheのレスポンスのヘッダーを確認する

それではApacheのレスポンスに含まれるヘッダーを順に見ていき、必要なものを取捨選択し、手直しの内容を確認していきましょう。
少し内容が多くなるので、あまり細かいことに興味がない方は飛ばし読みでも構いません。

Date

Date: Wed, 28 Oct 2020 07:57:45 GMT

RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.date

先程すでに見たところですが、まずはDateヘッダーについて見てみます。
Dateはレスポンスを生成した日時を表します。

今は固定の日時が返却されてしまっていますが、Pythonであればdatetimeモジュールを使えば日時の取得は簡単ですので、きちんとレスポンスを生成した日時を返すようにしましょう。

Server

Server: Apache/2.4.41 (Unix)

RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.server

こちらも先程すでに見ましたが、Serverヘッダーはレスポンスを生成したプログラムに関する情報を返します。
記載内容は特に指定はされていませんが、あんまり細かすぎる情報は書くべきではないとされていて、サーバー名やOS名ぐらいに留めておくことが一般的です。

今はApache/2.4.41 (Unix)で固定になっていますが、自分つけたオリジナルの名前にしてしまいましょう。

本書では、へなちょこWebサーバーのver.0.1、略してHenaServer/0.1を返すことにします。

皆さんはご自分でお好き名前をつけてあげてください。

Content-Location

Content-Location: index.html.en

RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.content-location

Content-Locationは、返却されたレスポンスを取得するための、代わりのURLを示します。

こちらは理解が少し難しいかもしれません。

今回のケースでいうと、Chromeは/というリソースを要求する際に、ついでにコンテントネゴシエーションというプロセスを行っています。

具体的には、Chromeは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

などのヘッダーを通じて
「私が理解できるコンテンツの形式はこれで、対応している圧縮形式はこれで、言語は日本語が一番欲しいけど、でも英語でもいいよ」
といったことを伝えています。

サーバー側は、その内容に応じて適切なレスポンスを生成しています。

この協調作業をコンテントネゴシエーションと言いますが、これはリクエストの仕方によって内容がコロコロ変わりうる、ということになります。

そのため、
「今回返却されたレスポンスと同じ内容が欲しい場合は、/じゃなくて代わりに/index.html.enにアクセスしてね」
ということをApacheが伝えているのです。

本書で作るサーバーはそこまで複雑なことはしませんので、このヘッダーは返却しないことにします。

Vary

Vary: negotiate

RFC: https://triple-underscore.github.io/RFC7231-ja.html#header.vary

Varyヘッダーは、ブラウザや中間サーバーがキャッシュを使用するかどうかを制御するためのヘッダーです。
このヘッダーに記載されたヘッダーが変化しない限りは、キャッシュを使って良いということを意味します。

今回でいうと、先程説明したコンテントネゴシエーションを行うヘッダーに変化がない限り、キャッシュされた内容を使いまわして良いですよ、とサーバーが伝えていることになります。

本書ではキャッシュ制御は行いませんので、このヘッダーは返却しないことにします。

TCN

TCN: choice

RFC: https://tools.ietf.org/html/rfc2295#section-8.5

こちらは少しマイナーなヘッダーで、Transparent Content Negotiationについて書かれた別のRFC 2295に記載されています。

どのようにコンテントネゴシエーションが行われたかを伝えるヘッダーですが、煩雑になってしまうためここでは説明は割愛します。

コンテントネゴシエーションは本書では行いませんので、このヘッダーは返却しないことにします。

Last-Modified

Last-Modified: Thu, 29 Aug 2019 05:05:59 GMT

RFC: https://triple-underscore.github.io/RFC7232-ja.html#header.last-modified

Last-Modifiedヘッダーは、コンテンツの内容が最後に変更された日時を返します。
一貫した最終変更日時を返却できるならば、このヘッダーは返すべきであるとされています。

なお、「一貫した最終変更日時を返却できない」状況というのは、リクエストごとに毎回内容がことなるURLなどではLast-Modifiedが同じなのに内容が違ったり、Last-Modifiedが違うのに内容が同じだったりしてしまい、意味のあるLast-Modifiedの値が存在しない場合などを指します。

本書ではURLごとに最終変更日時が意味を持ったり持たなかったりしますので、簡単のためこのヘッダーは返却しないことにします。