Real World HTTPの第１章１.４ HTTPの先祖（１）を読んだ

HTTP/0.9からHTTP/1.0への道のり

HTTP0.9

文書をブラウザからリクエストしてサーバーがデータを返すというウェブ技術の基本骨格はこの時点で完成していたと言える。 しかし、このプロトコルではできないことがいくつか存在した。

HTTP/0.9でできないこと

  • 1つのドキュメントを送る機能しかなかった

  • 通信される全ての内容はHTML文書であるという想定であったため、ダウンロードするコンテンツのフォーマットをサーバーから伝える手段がなかった

  • クライアント側から検索のリクエストを送る以外のリクエストを送信できなかった

  • 新しい文書を送信したり、更新したり、削除することはできなかった

HTTPにおける、わかりやすい基本的なヘッダー

  • ヘッダーは、「フィールド名: 値」という形式で本文の前に付加されていて、本文以外の全ての情報が含まれる

  • クライアントが送るヘッダーと、サーバーから送られてくるヘッダーの形式は全く同じである。ただし、使用されるフィールド名が異なり、ヘッダーの中には、リクエスト時のみに使われるもの、レスポンス時のみ使われるもの、両方で使われるものがある

クライアント → サーバー

  • User-Agent

    • クライアントが自分のアプリケーション名を入れるところ。サーバーはここを見てレスポンスを切り替えることがある。

  • Referer

    • サーバー側で参考にするための追加情報。クライアントがリクエストを送るときに見ていたページのURLを送ることによって、ページの参照元をサーバーが参照するのに用いる。

  • Authorization

    • 特別なクライアントにだけ通信を許可する際、認証情報をサーバーに伝える。 RFCでいくつかの標準的な形式を定めているが、AWSやGitHub APIなどのサービス独自の表記を求められることもある。
サーバー → クライアント

  • Content-Type

    • サーバーが返したファイルの種類を指定する。ここにはMIMEタイプと呼ばれる識別子（文字列、text/htmlなど）を記述する

  • Content-Length

    • ボディのサイズ

  • Content-Encoding

    • 何らかの圧縮が行われた場合に圧縮形式を説明する

  • Date

    • ドキュメントに日時

MIMEタイプ

ファイルの種類を区別するための文字列で、元は電子メールのために作られた。 ブラウザはファイルの種類に合わせて画面に表示したり、保存ダイアログを出したりといった機能を提供する。このときにファイルの種類を表す識別子がMIMEタイプ。 text/htmlのように大項目/詳細という表記をする。

電子メールとの違い

比較

  • ヘッダー + 本文という構造は同じ

  • HTTPのリクエストでは先頭にメソッド + パスの行が追加される

> GET /samplepath HTTP/1.0

< HTTP/1.0 200 OK