markdown 真实世界的HTTP - 歴史とコードに学ぶインターネットとウェブ技术 -

Posted 2021-05-06

Real World HTTP - 歴史とコードに学ぶインターネットとウェブ技術 -

# 第1章 HTTP/0.9から1.0への道のり P8
HTTP/0.9はとてもシンプルな仕組み、「文書をブラウザからリクエストしてサーバがデータを返す」ウェブという技術の基本骨格が完成していた。

HTTP/0.9には以下の欠点がある

 - 1つのドキュメントを送る機能しかない
 - 通信されるすべての内容はHTML文書であるという想定だったため、
ダウンロードするコンテンツのフォーマットをサーバから伝える手段がない
 - クライアント側から検索のリクエストを送る以外のリクエストを送信できなかった
 - 新しい文書を送信したり、更新したり、削除することはできなかった

## \<isindex>タグ
このタグを使うとテキスト入力欄ができて検索することができるようになった。  
![isindex](https://html-coding.co.jp/img/dictionary/html/isindex.png)

## HTTP1.0と0.9の違い
- リクエスト時にメソッドが追加された(GET)
- リクエスト時にHTTPバージョンが追加された
- ヘッダーが追加された(Host, User0Agent, Accept)
- リクエストの戦闘にHTTPバージョンと３桁のステータスコードが含まれるようになった
- リクエストと同じ形式のヘッダーが含まれるようになった。

## HTTPの先祖
電子メールで用いられていたヘッダー＋本文という構造を受け継いだ

### ヘッダー情報
「フィールド名：値」という形式で本文の前に付加する。  
[こちら](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields)にフィールド名の詳細が記載されている。

### MINEタイプとContent-Type P13-14
Content-Typeは、サーバーが返したファイルのフォーマットを表す文字列でMINEタイプと呼ばれる文字列が値として入っている。

#### MINEタイプ
MINEタイプはRFC1341にて定義されている。
ファイルの種類に合わせてブラウザの画面に表示したり、保存ダイアログを出したりといった機能を提供する際にファイルの種類を示すMINEタイプが使われる。

### Content-Typeとセキュリティ

#### 拡張子が表示されない
ウェブサイトによっては拡張子が送信されないことがある。
15年ぐらい前にはアクセスカウンターにはCGIがよく使われていたらしい。
例えばcounter.cgiというPerlで書かれたプログラムが画像を生成し”image/gif”のようなヘッダを返す仕組みだったらしい。

\<img src=“/cgi-bin/counter.cgi”>

#### 拡張子を推測する（Content Sniffing）
Internet ExplorerはMINEタイプではなく中身を見てファイル種類を推測しようとする。
これはContentSniffingと呼ばれる。text/plainであってもjsファイルと認識され実行されたりなどセキュリティホールの可能性がある。
そのため”X-Content-Type-Options: nosniff”と指定してブラウザに推測させないように指示するのが主流らしい。

### 電子メールとHTTPの違い
- HTTPのリクエストでは戦闘にメソッド＋パスの行が追加される
- HTTPのレスポンスでは戦闘にステータスコードが追加される

## HTTPの先祖（２）
USENETからメソッドとステータスコードという機能を受け継いだ

### メソッド
指定されたアドレスにあるリソースに対する操作をサーバに指示する。

標準機能
- GET:サーバに対して、ヘッダーとコンテンツを要求
- HEAD :サーバに対して、ヘッダーのみを要求
- POST:新しいドキュメントを投稿

オプション機能
- PUT:すでに存在するURLのドキュメントを更新
- DELETE:指定されたURLのドキュメントを削除する。削除に成功すると、削除されたURLは無効になる

### ステータスコード
３桁の数字でサーバがどのように応答したかひと目で分かるようになっている。

- 100番台:処理中の情報の伝達
- 200番台:成功時のレスポンス
- 300番台:サーバからクライアントへの命令
- 400番台: クライアントから送られたリクエスト異常
- 500番台:サーバ内部でエラーが発生

## リダイレクト
300番台のステータスコードを用いる。
リクエストされたページが別の場所に移動した時、
メンテナンス時にメンテナンスページに移動させる時、
モバイル専用サイトに移動させる時に利用される。

## URL

### URLとURIの違い
URIにはURN(Uniform Resource name)という、名前の付け方のルールが含まる。  
詳細は[こちら](https://ferret-plus.com/4637)に記載がある。  

URNは名前でしかないので、どこにあるのか、に関しては別に情報が必要となる。  
WEBシステムを取り扱う限りではURNは登場しないので、URLとURIを同一としても問題ない。

### 基本構造
フォーマット:スキーマ://ユーザ:パスワード@ホスト名:ポート/パス#フラグメント?クエリー
例:https://www.oreilly.co.jp/index.shtml

| value | type | content |
| ---- | ----- | ----- |
| スキーマ| https | ブラウザはスキーマを見て接続方法を変更 |
| ホスト名| www.oreilly.co.jp | 接続するサーバ情報 |
| パス | inde.shtml | 取得するリソースの指定 |

### basic認証は最新システムでは使わない
basic認証はURLにユーザ名・パスワードが含まれる。  
そのためアクセスログにURLが残るパスワードが漏洩する。

## ボディ

ヘッダーとの間に空行を挟むと、それ以降がボディとなる。  
送信時のデータ格納フォーマットがHTMLとXMLHttpRequestを使ったものがある。

### GETリクエスト時のボディは無視する
「サーバー−はメッセージボディを読み込む必要があるが、リクエストされたメソッドがボディのセマンティクスを定めていない場合はリクエストの処理時にメッセージボディは無視されるべきと」と記載がある。
原則としてメソッドのリクエストにはボディを含めないほうが良さそう、とりあえず動作保証は指定ない模様

# 第２章 HTTP/1.0のセマンティクス：ブラウザの基本機能の裏側