Hypertext Transfer Protocol (HTTP) はハイパーメディアドキュメントを転送するための、アプリケーション層 (日本語) のプロトコルです。これは Web ブラウザと Web サーバの間の通信に使用されますが、原理的には他の用途で用いることもできます。HTTP は伝統的なクライアントサーバモデル (日本語) に従い、クライアントがコネクションを開き、リクエストを送信し、レスポンスを受け取るまで待ちます。また HTTP はステートレスのプロトコルであり、サーバは 2 つのリクエストの間でいかなるデータ (状態) も保持しません。
HTTP は多くの場合 TCP/IP 層を基にしますが、任意のコネクション指向のトランスポート層 (日本語) プロトコルを基にすることができます。
{{ 英語版章題("A brief history of HTTP") }}
HTTP の簡潔な歴史
単一のメソッド (GET) を持ち、HTML ページだけを返すプロトコルであった当初の構想から、HTTP プロトコルは何度か改訂されてきました。最初に文書化されたバージョンは 1991年の HTTP/0.9 であり、当初のバージョンに対応します。とてもシンプルで、{{ HTMLElement("isindex") }} 要素を用いた基本的な検索機能や '?' 文字を用いた URL の拡張機能がありました。
1992 年に、いくつか小さな変更を加えたバージョンが HTTP/1.0 になったと発表されました (1996 年 5 月に RFC 1945 で完成しました)。前のバージョンからの主要な改善点は、HTML ファイルだけでなく画像、動画、スクリプト、CSS ドキュメントなど、さまざまな種類のファイルの転送が可能になったことです。これは Content-Type: ヘッダと連携して MIME タイプ を用いることで実現しました。
1995 年に IETF は、後に HTTP/1.1 となる新たなバージョンの HTTP の開発を始めました。これは急速に広く使われるようになり、また 1997 年には RFC 2068 で公式に標準化され、さらにその 2 年後に RFC 2616 で小規模な修正が行われました。
HTTP/1.1 では確立済みのコネクションを後続のリクエストで再使用できるようになり、リクエスト間のレイテンシを低減することでプロトコルのパフォーマンスが大きく向上しました。これは特に、画像やスタイルシートなど複数のファイルを続けて読み込まなければならない、複雑な HTML ドキュメントで特に有用です。また Host: ヘッダを導入しており、これは 1 台のサーバが複数の Web サイトのリクエストを受けるために、特定のポートで待ち受けることを可能にします。これは 1 台のサーバに複数の Web サイトを配置することを可能にし、ホスティングのコストを大きく削減します。
それ以来、HTTP プロトコルは新しい ヘッダ を追加することで成長しており、プロトコルを根本的に変更することなく新たな動作を定義しました。未知のヘッダは、サーバやクライアントによって単に無視されます。
現在 HTTP/1.1 は IETF の HTTPbis Working Group によって改訂されています。
{{ 英語版章題("An HTTP session") }}
HTTP セッション
HTTP はクライアントサーバプロトコルですから、HTTP セッションは 3 段階で構成されます:
- クライアントは TCP コネクション (トランスポート層が TCP ではない場合は、他の適切なコネクション) を確立します。
- クライアントはリクエストを送り、その応答を待ちます。
- サーバはリクエストを処理して、ステータスコードや適切なデータを含む応答を返信します。
HTTP/1.1 より第 3 段階の後にコネクションは閉じられなくなり、クライアントはその時点で別のリクエストを発行することができます。従って、第 2 段階と第 3 段階を複数回行うことができます。
{{ 英語版章題("Establishing a connection") }}
コネクションの確立
HTTP はクライアントサーバプロトコルですから、コネクションを確立するのは常にクライアントです。HTTP のコネクションを開くとは、実際は下層のトランスポート層、通常は TCP のコネクションを確立することです。
TCP では、HTTP サーバの既定のポートは 80 ですが、8000 や 8080 など他の番号が使われることもあります。読み込むページの URL にはドメイン名とポート番号の両方が含まれますが、後者は 80 である場合に省略できます。
{{ 英語版章題("Sending a client request") }}
クライアントのリクエスト送信
コネクションを確立すると、ユーザエージェントはリクエストを送信可能になります。(代表的なユーザエージェントは Web ブラウザですが、これに限りません) クライアントのリクエストは CRLF (キャリッジリターンの後にラインフィード) で区切られたテキストのディレクティブで構成され、3 つのブロックに分けられます:
- 最初の行は、以下のパラメータを持つリクエストメソッドを含みます:
- ドキュメントのパス、すなわち絶対 URL からプロトコル名とドメイン名を除いたものです。
- 使用する HTTP プロトコルのバージョン。
- 後続の行は各々具体的な HTTP ヘッダを表し、サーバに対してどの種類 (例えば言語や MIME タイプ) のデータが適切かを示す情報や、サーバの動作を変える (例えばすでにキャッシュされている場合は応答を送信しない) 情報を与えます。これらの HTTP ヘッダは空行で終わるブロックを構成します。
- 最後のブロックは省略可能なデータブロックで、ここには主に POST メソッドで使用される追加のデータを含みます。
{{ 英語版章題("Examples of requests") }}
リクエストの例
- developer.mozilla.org のルートページ、すなわち https://developer.mozilla.org/ を読み込み、また可能であればユーザエージェントはフランス語のページを希望することをサーバに伝えます:
GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr
最後の空行は、ヘッダブロックとデータブロックを分けていることに注意してください。この例では
Content-Length:HTTP ヘッダがありませんのでデータブロックは空であり、サーバはヘッダの終わりを示す空行を受け取るとただちにリクエストを処理できます。 - フォームの入力結果を送信します:
POST /contact_form.php HTTP/1.1 Host: developer.mozilla.org Content-Length: 64 Content-Type: application/x-www-form-urlencoded name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
{{ 英語版章題("Structure of a server response") }}
サーバレスポンスの構造
接続したエージェントがリクエストを送信すると、Web サーバはそのリクエストを処理して、最終的にレスポンスを返信します。クライアントのリクエスト同様にサーバのレスポンスはテキストのディレクティブで構成され、CRLF で区切られ、3 つのブロックに分けられます:
- 最初の行はステータス行で、受け入れた HTTP バージョンとステータス要求で構成されます (そして、人間に読めるテキストであることを意味します)。
- 後続の行は各々具体的な HTTP ヘッダを表し、クライアントに対して送信したデータに関する情報 (例えば種類、サイズ、圧縮方法、キャッシュ情報) を与えます。クライアントのリクエストの HTTP ヘッダブロックと同様に、これらの HTTP ヘッダも空行で終わるブロックを構成します。
- 最後のブロックはデータブロックで、(もしあれば) データを含みます。
{{ 英語版章題("Examples of responses") }}
レスポンスの例
- Web ページについて成功したことの応答:
HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html <!DOCTYPE html... (ここにサイズが 29769 バイトの、要求された Web ページが置かれます)
- 要求されたリソースは永続的に移動されたことの通知:
HTTP/1.1 301 Moved Permanently Server: Apache/2.2.3 (Red Hat) Content-Type: text/html; charset=iso-8859-1 Date: Sat, 09 Oct 2010 14:30:24 GMT Location: https://developer.mozilla.org/ (これはリソースの新しいリンクです。ユーザエージェントはこちらを読み込むでしょう) Keep-Alive: timeout=15, max=98 Accept-Ranges: bytes Via: Moz-Cache-zlb05 Connection: Keep-Alive X-Cache-Info: caching X-Cache-Info: caching Content-Length: 325 (ユーザエージェントがリンクをたどれない場合に表示する、既定のページを含むコンテンツです) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p> <hr> <address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address> </body></html>
- 要求されたリソースが存在しないことの通知:
HTTP/1.1 404 Not Found Date: Sat, 09 Oct 2010 14:33:02 GMT Server: Apache Last-Modified: Tue, 01 May 2007 14:24:39 GMT ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1" Accept-Ranges: bytes Content-Length: 10732 Content-Type: text/html <!DOCTYPE html... (欠けているリソースをユーザが見つけることを支援する、サイト毎にカスタマイズされたページを含みます)
{{ 英語版章題("Persistent connections") }}
持続的なコネクション
持続的なコネクションは、HTTP/1.1 で導入されました。これは同一の TCP コネクション (HTTP が TCP/IP 上に構築されていない場合は、特定のトランスポート層のコネクション) で複数のリクエストを送信可能にします。この機能には以下のような利点があります:
- コネクションを再使用できますので、コネクションのレイテンシを抑えるためにリクエストを パイプライン化 できます。
- 開閉する TCP コネクションを減らすことで、CPU の使用時間を抑えます。
- TCP パケットの総量 (コネクションを開いたり閉じたりする TCP パケット) を削減することで、ネットワークの混雑を軽減します。
- TCP スタックがネットワークの混雑を検出したり、送受信のウィンドウサイズを適正化したりするための時間を増やします。
- HTTP の適応性が向上します: エラーのレスポンスを受け取ってもコネクションが閉じられないため、機能の確認にかかるコストがかなり下がります。
{{ 英語版章題("HTTP request methods") }}
HTTP リクエストメソッド
リクエストメソッドは、サーバによって実行されるアクションを示します。HTTP/1.1 標準仕様では 7 つのメソッドをを定義しており、また他のメソッドを後で追加することも認めています。長い年月の間に、WebDAV などいくつかの標準仕様が追加されました。現在 IETF の HTTPbis Working Group は、それらすべてを一覧化するために IANA レジストリで作業を行っています。サーバが未知のリクエストメソッドを受け取った場合は、501 Not implemented レスポンスを返さなければなりません。一方、既知のメソッドであってもそれに答えないよう設定されている場合は、405 Method not allowed レスポンスを返さなければなりません。サポートが必須のメソッドは 2 つあり、HEAD および GET です。他すべてのメソッドのサポートは任意です。
標準仕様では 2 種類の明確な意味が定義されており、Web 開発者にとって重要です: それは {{ 原語併記("安全", "safety") }} な性質と、{{ 原語併記("べき等", "idempotent") }} な性質の 2 種類です。
{{ 英語版章題("Safe methods") }}
安全なメソッド
{{ 原語併記("安全なメソッド", "safe method") }}とは、サーバ上での副作用がないメソッドです。言い換えると、この特性はメソッドがデータの取り出しにしか用いてはならないことを意味します。HTTP/1.1 で定義されている安全な HTTP メソッドは以下のとおりです:
- GET、これはリクエストの URI が示す情報を取り出すために用います。この情報はその場で生成されたり、{{ httpheader("If-Modified-Since") }}、{{ httpheader("If-Unmodified-Since") }}、{{ httpheader("If-Match") }}、{{ httpheader("If-None-Match") }}、{{ httpheader("If-Range") }} HTTP ヘッダのいずれかを付加して条件付きの GET になったりする場合があります。後者では、すべての条件を満たす場合にのみ情報が返信されます。
- HEAD、これはメッセージボディを送らないこと以外は GET と同じです。
- 安全なメソッドはすべて、べき等でもあります。
- 副作用がないとは、GET メソッドの場合は電子商取引サイトでの注文など、サーバ外部でのアクションを起こすことに用いてはならないことを意味します。副作用が必要である場合は、POST などべき等ではないメソッドを用いるべきです。
- ページがスクリプトによりその場で生成されるとき、スクリプトエンジンはページが GET で要求された後にそのデータブロックを取り除くかのように処理を行うでしょう。これはスクリプトで実装されている GET が安全である限り問題になりませんが、もし (電子商取引サイトで注文を行うような) 副作用を持つ場合は、HEAD メソッドも副作用を引き起こすでしょう。Web 開発者は、GET および HEAD メソッドの両方が安全に実装されていることを確実にしなければなりません。
{{ 英語版章題("Idempotent methods") }}
べき等なメソッド
{{ 原語併記("べき等なメソッド", "idempotent method") }}とは、複数の同じリクエストによるサーバ上での副作用と単一のリクエストによる副作用が同じになるメソッドです。
- 安全なメソッドである HEAD および GET はサーバ上での副作用がないことから、べき等でもあります。
- PUT は新たなリソースをサーバへアップロードします。異なるリソースがすでにある場合は、それを置き換えます。一方リソースが存在しない場合は、それを新規作成します。
- DELETE はリソースをサーバから削除します。
{{ 英語版章題("Other methods") }}
その他のメソッド
- POST はサーバ上でアクションを起こします。このメソッドには副作用があり、取引の注文、データベースの変更、フォーラムへのメッセージ投稿などを行うために用いることができます。
- OPTIONS はクライアントと (プロキシサーバを経由して) サーバの間で使用可能な通信オプションを要求します。このメソッドは主に、クロスオリジンリクエストを行っても安全であるかを知るためプリフライトの前に送信されます。
注意: クロスオリジンリクエストのプリフライトは、OPTIONS メソッドを許可しないかサポートしないサーバでは実行できません。 - TRACE は、クライアントと (プロキシサーバを経由して) サーバの間で行う ping の一種です。
PROPFIND や PATCH などその他多くのメソッドは、WebDAV など別の IETF 標準トラック RFC で定義されています。
CONNECT メソッドは RFC 2817 で定義されています。
{{ 英語版章題("HTTP Requests Methods in HTML Forms") }}
HTML フォームでの HTTP リクエストメソッド
HTML では {{ HTMLElement("form") }} 要素の {{ htmlattrxref("method", "form") }} 属性、あるいは {{ HTMLElement("input") }} または {{ HTMLElement("button") }} 要素の {{ htmlattrxref("formmethod", "input") }} 属性で別のメソッドを指定することができます。ただし、これらの属性ですべての HTTP メソッドが指定できるわけではありません。HTML 仕様書では、GET および POST だけが許可されています。
{{ 英語版章題("HTTP response codes") }}
HTTP レスポンスコード
クライアントのリクエストに応えるとき、サーバはリクエストが正しく処理されたかを示す 3 桁の数値を返信します。これらのコードは、5 つのカテゴリにグループ化できます:
- 情報レスポンス (
1xx形式) は、暫定的なレスポンスです。ほとんどの場合エンドユーザ、Web 開発者、ウェブマスターのいずれも、これらのレスポンスについて悩む必要はありません。もっとも多いレスポンスは 100 Continue であり、クライアントはリクエストの送信を続けてよいことを示します。注意: HTTP/1.0 では情報レスポンスコードが定義されておらず、このバージョンのプロトコルを使う場合は情報レスポンスを返してはなりません。 - 成功レスポンス (
2xx形式) は、リクエストの処理に成功したことを示します。200 OK レスポンスがこの種のレスポンスでもっとも多くみられますが、ファイルや動画や音楽などメディアデータを読み込む際に 206 Partial Content もよくみられます。 - リダイレクションレスポンス (
3xx形式) は、クライアントが要求したリソースが移動されており、サーバが直接提供できないことを示します。これらのレスポンスのほとんどは要求されたリソースがどこにあるかを表す情報を含んでいます。ユーザエージェントはたいてい、ユーザの追加操作なしにそのリソースを取り込みます。この種のレスポンスでもっとも多いものは、与えられた URI はもはや有効ではなく別の場所に移動されたことを示す 301 Moved Permanently と、リソースは別の場所へ一時的に移動されたことを示す 302 Found です。
注意: ウェブマスターに対して、例えばサイトの再編中に別の URI へページを移動しているときは 301 Moved Permanently リダイレクションの設定を推奨します。これによりユーザは今までどおりリソースへのリンクをたどることができ、また検索エンジンや他のサービスに対してリソースの新しい場所を伝えて、サービスが持つメタデータを転送することが可能になります。301 Moved Permanently レスポンスには適切なキャッシュのヘッダを付加することも重要であり、この情報はクライアントにキャッシュされて、リソースを読み込むときに元の URI に不必要なリクエストを行うことを防ぎます。 - クライアントエラーレスポンス (
4xx形式) は、クライアントが送信したリクエストが不正であるか、処理をするのに充分ではないことを示します。このようなレスポンスでもっとも多いものは、要求された URI が存在しない場合に返信される 404 Not Found ですが、リクエストが正しい HTML リクエストではない (発生するべきでないことですが、ユーザエージェントやまれにサーバのバグを示すことがあります) 場合に送られる 400 Bad Request や、クライアントは存在するリソースを要求したが転送が許可されていない (ディレクトリの内容など) 場合に送られる 403 Forbidden など他のレスポンスがエンドユーザに返信されることもあります。 - サーバエラーレスポンス (
5xx形式) は、クライアントの正常なリクエストを処理する際にサーバで問題が発生したことを示します。これらのレスポンスでもっとも多い 2 つは、サーバでの不具合を示す一般的なエラーコードである 500 Internal Server Error と、メンテナンスやデータベースの障害によるサービス停止など一時的な問題でサーバがリクエストを処理できないことを示す 503 Service Unavailable です。
Web 開発者がその他のレスポンスコードの多くに出くわすことはないと思われますが、XMLHTTPRequest 機能を用いてリクエストを作成する場合は一般的ではないレスポンスコードをみることがあるかもしれません。
{{ 英語版章題("More on redirection responses") }}
リダイレクトレスポンスの補足
Gecko 9.0 {{ geckoRelease("9.0") }} より、javascript: URI を指定する (301 や 307 などの) リダイレクションは実行されません。その代わりに、不正な接続のエラーが表示されます。これはクロスサイトスクリプティング攻撃の回避に役立ちます。詳しくは {{ bug("255119") }} をご覧ください。
{{ 英語版章題("HTTP headers") }}
HTTP ヘッダ
HTTP ヘッダは、クライアントやサーバがリクエストやレスポンスで追加情報を渡すことを可能にします。リクエストヘッダは、大文字小文字を区別しないヘッダ名、コロン ':'、値で構成されます (CRLF は含まれません)。値の前にあるホワイトスペース文字は無視されます。
ヘッダは、それらが現れる状況に従ってグループ化されます:
- 一般ヘッダ
- これらのヘッダはリクエストとレスポンスの両方に適用されますが、最終的にボディで転送されるデータとの関連はありません。従ってこれらは、メッセージの転送中にのみ適用されます。このヘッダは少なく、また新たなヘッダは HTTP プロトコルのバージョン番号を上げることなく追加することができません。HTTP/1.1 での全一覧は {{ httpheader("Cache-Control") }}、{{ httpheader("Connection") }}、{{ httpheader("Date") }}、{{ httpheader("Pragma") }}、{{ httpheader("Trailer") }}、{{ httpheader("Transfer-Encoding") }}、{{ httpheader("Upgrade") }}、{{ httpheader("Via") }}、{{ httpheader("Warning") }} です。
- リクエストヘッダ
- これらのヘッダは、読み込むリソースやクライアント自身のより詳細な情報を与えます。この中にはキャッシュ関連のヘッダ、{{ httpheader("If-Modified-Since") }} など GET メソッドを条件付き GET に変換するヘッダ、{{ httpheader("Accept-Language") }} や {{ httpheader("Accept-Charset") }} などユーザの設定情報、{{ httpheader("User-Agent") }} などクライアント情報のヘッダがあります。公式には、新たなリクエストヘッダは HTTP プロトコルのバージョン番号を上げることなく追加することができません。しかし、サーバとクライアントの双方がその意味に同意する場合は新たなリクエストヘッダが追加されることが一般的です。この場合、クライアントはそのようなヘッダが適切にサーバで処理されると仮定してはなりません。未知のリクエストヘッダはエンティティヘッダとして処理されます。
- レスポンスヘッダ
- これらのヘッダは返信されるリソースに関して実際の場所 ({{ httpheader("Location") }}) などや、サーバ自身に関して名前やバージョン ({{ httpheader("Server") }}) などの詳細情報を与えます。新たなレスポンスヘッダは HTTP プロトコルのバージョン番号を上げることなく追加することができません。しかし、サーバとクライアントの双方がその意味に同意する場合は新たなレスポンスヘッダが追加されることが一般的です。この場合、クライアントはそのようなヘッダが適切にサーバで処理されると仮定してはなりません。未知のレスポンスヘッダはエンティティヘッダとして処理されます。
- エンティティヘッダ
- これらのヘッダはエンティティのボディに関して、長さ ({{ httpheader("Content-Length") }}) や識別用のハッシュ ({{ httpheader("Content-MD5") }}) や MIME タイプ ({{ httpheader("Content-Type") }}) などの詳細情報を与えます。新たなエンティティヘッダは HTTP プロトコルのバージョン番号を上げることなく追加することができます。
またヘッダは、キャッシュ・非キャッシュプロキシサーバがどのように処理するかに応じてグループ化されます:
- エンドツーエンドヘッダ
- これらのヘッダはメッセージの最終的な宛先に転送しなければなりません。つまり、リクエストメッセージにおけるサーバまたはレスポンスメッセージにおけるクライアントです。このようなヘッダは、中間のプロキシが変更せずに再伝送しなければならず、またキャッシュには保存しなければならないことを意味します。
- ホップバイホップヘッダ
- これらのヘッダは単一のトランスポート層の接続にのみ意味を持ち、プロキシは再伝送やキャッシュを行ってはなりません。これは以下のようなヘッダがあります: {{ httpheader("Connection") }}、{{ httpheader("Keep-Alive") }}、{{ httpheader("Proxy-Authenticate") }}、{{ httpheader("Proxy-Authorization") }}、{{ httpheader("TE") }}、{{ httpheader("Trailers") }}、{{ httpheader("Transfer-Encoding") }}、{{ httpheader("Upgrade") }}。ホップバイホップヘッダは {{ httpheader("Connection") }} 一般ヘッダを用いて設定される場合があることに注意してください。
各ヘッダの具体的な文法について学ぶには、HTTP ヘッダの包括的な一覧にある項目をご覧ください。
{{ 英語版章題("Useful request headers") }}
有用なリクエストヘッダ
数多くある HTTP リクエストヘッダの中には、正しく設定することでとても有用になるものがあります。XMLHTTPRequest を用いて自分自身でリクエストを構築している場合や、拡張機能を作成して XPCOM を用いたカスタム HTTP リクエストを送信するときは、ユーザの設定に基づきブラウザによってよく設定されるヘッダの存在を確実にすることが重要です。
- リソースの言語の制御
- Firefox など多くのユーザエージェントはユーザに、受け取るリソースの言語を設定することを可能にしています。ブラウザはこの設定を {{ httpheader("Accept-Language") }} ヘッダに変換します。具体的な HTTP リクエストを構築するときにこのようなヘッダを含めることは、Web 開発者にとってよい習慣です。
- 条件付き GET の利用
-
キャッシュは、Web ページの表示を高速化するための主要なツールです。
XMLHTTPRequestによって Web ページの一部が更新される場合でも、それが変更された場合にのみ新しいコンテンツを取り込むために {{ httpheader("If-Modified-Since") }} (および類似の) ヘッダを用いるのはよい考えです。この手法によりネットワークの負荷が軽減します。
{{ 英語版章題("Useful response headers") }}
有用なレスポンスヘッダ
Web サーバの設定は、Web サイトの良好なパフォーマンスや最適なセキュリティを確保するために重要な部分です。数多くある HTTP レスポンスヘッダの中には、明らかに重要かつ設定すべきであるものがあります。
{{ 英語版章題("Restricting framing") }}
フレームの制限
ある種のクロスサイトスクリプティング (XSS) 攻撃は、第三者のコンテンツを {{ HTMLElement("frame") }} や {{ HTMLElement("iframe") }} に含められることを利用します。この危険性を軽減するために、現代のブラウザは X-Frame-Options: レスポンスヘッダを導入しました。このヘッダを値 DENY で設定すると、ブラウザがそのリソースをフレーム内に読み込むことを防止します。重要なリソース (フォーミュラリーや重要な情報を含むリソースなど) でこのヘッダを用いると、XSS 攻撃によって引き起こされる危険性を減らすでしょう。この HTTP レスポンスヘッダは、XSS の危険性を軽減する唯一の方法ではないことに注意してください。Content Security Policies の設定なども有用です。
{{ 英語版章題("Compression") }}
圧縮
転送されるデータの量を最小化すると、Web ページの表示が速くなります。CSS スプライト など多くの技術はサイト自身で適用されるにもかかわらず、データの圧縮は Web サーバレベルで設定しなければなりません。圧縮を設定すると、クライアントが {{ httpheader("Accept-Encoding") }} リクエストヘッダとともに要求したリソースは適切な方法で圧縮され、{{ httpheader("Content-Encoding") }} レスポンスヘッダとともに返信されます。Apache 2 においてこれらの設定は、mod_deflate モジュールを用いて行われます。
{{ 英語版章題("Controlling cache") }}
キャッシュの制御
HTTP キャッシュは同一のリソースを、変更されていないにもかかわらず何度も読み込むことを防ぐ技術です。サーバで正しいレスポンスヘッダを設定することで、ユーザエージェントがデータを適切にキャッシュすることができます。これを行うには、以下の点に注意してください:
- 静的なリソースでは、遠い未来に設定した {{ httpheader("Expires") }} レスポンスヘッダを与えます。この方法では、リソースはユーザエージェントが自身の理由 (キャッシュ容量の上限に達したなど) で消去されるまでの間、キャッシュにとどまります。
注意: Apache では、相対的な期限を定義するために .htaccess で ExpiresDefault ディレクティブを用います。例:
ExpiresDefault "access plus 1 month" - 動的なリソースでは {{ httpheader("Cache-control") }} レスポンスヘッダを与えます。理論上、安全なメソッド (GET または HEAD) または単一のべき等なメソッド (DELETE や PUT) で行われた HTTP リクエストはすべてキャッシュされるでしょう。しかし実際は、レスポンスのキャッシュが不適切な副作用を引き起こさないか注意深く調べることが必要です。
{{ 英語版章題("Setting the correct MIME types") }}
正しい MIME タイプの設定
MIME タイプはクライアントに対して、転送するドキュメントの種類を伝える機能です: Web において、ファイル名の拡張子は意味を持ちません。従って、サーバは各々のドキュメントともに正しい MIME タイプを転送するよう適切に設定することが重要です: ユーザエージェントはたいてい MIME タイプを、読み込んだリソースに対して行う既定のアクションを決めるために使用します。
- Apache では .htaccess で、ファイル拡張子と与えられた MIME タイプを、
AddTypeディレクティブを用いて関連づけることができます。例:AddType image/jpeg jpg - 多くの Web サーバは未知の種類のリソースについて、既定の
application/octet-streamMIME タイプを送ります。セキュリティの理由で、Firefox など多くのブラウザはこのようなリソースに既定のアクションを定義することを許可せず、リソースを使用するためにディスクへ保存することをユーザに強制します。以下のファイル種類について、正しく設定されていないサーバでよく発生する事例があります:-
RAR でエンコードされたファイル。理想はエンコードされたファイルの実際の種類を設定できることです。しかしこれはたいていの場合できません (サーバがそれを知ることができず、またこれらのファイルは種類が異なる複数のファイルを含むためです)。この場合、サーバは
application/x-rar-compressedMIME タイプを送信するように設定します。そうしなければ、一部のユーザがそれらのファイルに対して、既定の有用なアクションを定義できなくなるでしょう。 -
音声および動画のファイル。適切な MIME タイプを持つリソースだけが、{{ HTMLElement("video") }} または {{ HTMLElement("audio") }} 要素を用いたときに認識および再生されます。音声および動画のリソースに対して正しい MIME タイプを用いるよう注意してください。
-
プロプライエタリなファイル種類。プロプライエタリなファイルを提供するときは、特に注意が必要です。このようなファイルに x- 接頭辞付きのタイプを与え忘れないようにしてください。そうしなければ、特有の操作ができなくなるかもしれません。これは Keyhole Markup Language (日本語) を用いるリソースで特に当てはまり、ユーザ体験を最適化するために
application/vnd.google-earth.kml+xmlとして提供するべきです。
-
{{ 英語版章題("See also") }}
参考情報
{{ languages( { "en": "en/HTTP"} ) }}