HTTP(Hyper Text Transfer Protocol)の基礎
|
|
サーブレットはなにもHTTPベースに限定したものではなく、多様なクライアント−サーバ間通信に対応できる。しかしながら、基本はHTTPであり、まずHTTPの基礎を理解しておくことが重要である。HTTPの前にHTMLの理解が前提だが、これは殆どの読者はマスターしているはずである。なお、次のURLに日本語で判りやすい解説があるので、そちらも参照されたい。
http://www.mars.dti.ne.jp/~torao/program/protocol/http.html
RFC 2616に従って日本語で解説したものとしては次のURLがある。
HTTPは、クライアント／サーバー間の、要求／応答のパラダイムからなるTCP/IP網上の、極めて簡単なアプリケーションレベルのプロトコルである。取り交わすメッセージの形式はSMTPに類似している。HTTPにはHTTP 1.0と、その発展型であるHTTP 1.1の二つのバージョンが存在する。RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1はW3Cのホームページなどから容易に取得できる。
|
|
|
|
HTTP 1.0では、上図のように要求／応答のトランザクション毎にTCP接続が切れてしまう（HTTPはステートレスのプロトコルであると言われる由縁のひとつである）。通常のホームページなどでは、ひとつの画面に多くの上図のセッションを要することになり、非効率的である。HTTP 1.1ではひとつの継続した接続中に複数のトランザクションを許容し、高速化している。またキャッシュによる高速化と帯域の節約、Chunked-transfer（大きな塊を厚切りに分割した転送）エンコーディングによる高速化、単一のIPアドレスで複数のドメイン対応としてIPアドレスを効率的に使用するなどの改良もなされている。
付章1-1 HTTPトランザクションの構成
Request（要求）、Response（応答）ともにメッセージ形式は前述のようにSMTPのMIMEメール形式に類似している。
- 初期行(Initial Line)
- ゼロまたはそれ以上のヘッダ行(HeaderLine)
- 空白行(Blank Line)
- オプショナルな本文(Message Body)
テキスト、ファイル、バイナリデータなど
各行は復帰改行(CRLF)で終端される。
初期要求行(Initial Request Line)
初期行は応答よりは要求の内容で異なってくる。要求行はスペースで区切られた3要素、即ちメソッド名、要求するリソースのローカルパス、使用中のHTTPバージョンからなる。典型的な要求行は次のようなものである。
GET /path/to/resource/index.html HTTP/1.0
ここで、
- GETはもっとも一般的に使用されるHTTPのメソッドである。GETの意味するところは、「このリソースが欲しい」である。その他のメソッドとしてはPOSTやHEADなどがあり、これらの詳細は後述する。メソッド名はかならず大文字のこと。
- パスはURL(Uniform Resource Locator)のホスト名以降の部分であり、「要求URI」とも呼ばれる。URI(Uniform Resource Indicator)は、URLと類似ではあるが、より一般的である。
- HTTPバージョンは、常に”HTTP/x.x”の形式をとり、大文字で記入する。
初期応答行(Initial Response Line)
初期応答行は「ステータス行」とも呼ばれ、これもスペースで区切られた3要素からなる。即ち、HTTPバージョン、要求に対する結果を示す応答ステータスコード、及び応答コードを記述する英文の「理由応答句」である。
典型的な応答行は次のようなものである。
HTTP/1.0 200 OK
あるいは、
HTTP/1.0 404 Not Found
ここで、
- HTTPバージョンは要求行と同じ形式をとり、大文字の”HTTP/x.x”である
- ステータスコードは、コンピュータが理解できる為にコードで表現したものであり、理由応答句は人が持て理解できる為にあり固定されてはいない（処理系によっては異なる）。
- ステータスコードは3桁の数字であり、最初の桁は応答のカテゴリを意味する。
1xx は単なる情報の為のメッセージであることを意味する(HTTP 1.1 にて定義)
2xx はある種の成功を意味する
3xx はクライアントにリソースが他のURLへのリダイレクトであることを通知
4xx はクライアント側のエラーを意味する
5xx はサーバ側のエラーを意味する
もっとも一般的なステータスコードを示すと：
200 OK
該要求は成功裏に終了し、結果のリソース（例えばファイルあるいはスクリプト出力）はメッセージ本体で返されていることを示す。
404 Not Found
要求されたリソースは存在しない
301 Moved Permanently
302 Moved Temporary
303 See Other (HTTP 1.1 only)
該リソースは他のURL（応答ヘッダのLocationで示されている）に移動しており、クライアント側で自動的に検索すべきものである。このコードは良くCGIスクリプトでブラウザを存在しているファイルにリダイレクトするために使用される。
500 Server Error
サーバ側での予期せぬエラー。よくある理由としては、サーバ側のスクリプトの構文誤り、実行誤り、あるいは正常に動作しないなどである。
完全なステータスコードのリストはRFCドキュメントを参照のこと。
ヘッダ行(Header Lines)
ヘッダ行は、要求または応答に関する、あるいはメッセージ本体で送られるオブジェクトに関する情報を示す。ヘッダ行は通常のテキストヘッダの形式、即ち1行1ヘッダ、”Header-Name: Value”の形式、CRLFによる行終端となっている。これはSMTPメールやNewsポスティングなどのフォーマット(RFC822, Section 3)と同じである。
詳細は：
· 上記のとおりCRLFで終了しなければならないが、LFのほうを正しく処理すること
· ヘッダ名は大文字／小文字を区別しない。（数値は別）
· “:”と数値の間は任意の数のスペースあるいはタブを許容
· スペースまたはタブで始まるヘッダ行は、その前のヘッダ行の部分であり、見易い様に複数行にしたものである
従って以下の二つのヘッダは等価である：
Header1: some-long-value-1a, some-long-value-1b
Header1: some-long-value-1a,
some-long-value-1b
TCP 1.0では、総てが必須ではないが16ヘッダが定義されている。HTTP 1.1では46ヘッダと要求には必須の1ヘッダ（Host:）が定義されている。ネット社会の礼儀として、以下のヘッダを要求メッセージに含めることが好ましい。
- From: これは誰がこの要求を、あるいはどのプログラムがこの要求を発生したかのE-mailアドレスである。（ただしこのヘッダの送出はプライバシーの関係でユーザが設定できるようにすること）
- User-Agent: このヘッダは要求をしているプログラムを識別する。形式は、”Program-name/x.xx”である。ここに、x.xxは該プログラムの英数文字で記述したバージョンである。例えば,Netscape 3.0は”User-agent: Mozilla/3.0Gold”なるヘッダを送出する。
上記ヘッダはWeb管理者のトラブル解析に有効である。しかしながらユーザ情報を開示してしまうので、Web管理者のログ取得のニーズとユーザのプライバシーのニーズとのバランスを取らねばならない。
サーバサイドでは、次のようなヘッダを応答メッセージに含めることが好ましい：
Server: User-Agent:と類比される。”Program-name/x.xx”の形式でサーバソフトウエアの識別を行う。例えば、Apacheサーバのベータ版は、”Server: Apache/1.2b3-dev”をかえす。
Last-Modified: 返送中のリソースの最終変更日付を示すヘッダ。キャッシングやその他の帯域節約処理に使用される。以下の形式のGMTを使用すること。
Last-Modified: Fri, 31 Dec 1999 23:59:59 GMT
メッセージ本体(Message Body)
ヘッダ行の後に、ブランク行をおいてその後にデータの本体を置くことができる。応答メッセージにおいては、クライアントに返す要求されたリソースを置く場所であり、これがもっとも一般的なメッセージ本体の使用法である。それ以外にも、該リソースの説明文なども置いたりする。要求メッセージにおいては、サーバに送るユーザ入力のデータやアップロードするファイルなどの置き場所となる。HTTPメッセージが本体を持つ場合は該本体に関するヘッダ行が通常含まれる。特に：
- Content-Type: MIME(Multi-Information Mail Extension)タイプのデータが本体にあるときに使用する。例えばtext/htmlやimage/gifなど。
- Content-Length: 本体のバイト数を示すヘッダ。
付章1-2 HTTP交信例
以下のURLのファイルを検索することを考える。
http://my-server.cresc.co.jp/file.html
クライアントはまずmy-server.cresc.co.jpなるホストに対して受付ポート番号80（ポート番号がURLに指定されていないので、デフォルトの80を使用する）でソケット接続を行う。次に、つぎのようなメッセージを該ソケットに送出する。
GET /path/file.html HTTP/1.0
FROM: terry@cresc.co.jp
User-Agent: HTTPTool/1.0
[空白行]
サーバは、例えば次のような応答を返す。
HTTP/1.0 200 OK
Date: Tue, 06, Feb 2000 23:59:59 GMT
Content-Type: text/html; charset=iso-2022-jp
Content-Length: 1234
<html>
<head>
<META HTTP-EQUIV=\”Content-Type\” CONTENT=\”text/html; charset=iso-2022-jp\”>”
<title>Omedetou</title>
</head>
<body>
<center>
<h1>無事届きました</h1>
</center>
<p>
良かった！
</body>
</html>
応答を送出終了したらサーバはソケットを閉じる。
付章1-3 その他のHTTPメソッド
GET以外にも、HEAD及びPOSTメソッドが良く使われるので、以下にそれを紹介する。HTTP/1.0で定義されているメソッドの全ては、OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT及び拡張メソッドである。
HEADメソッド
HEADはGETと同じ要求ではあるが、応答メッセージのヘッダを返す（つまり該リソースの本体部分は送り返さない）ことを期待しているところが異なる。このことは、リソースをダウンロードすることなく該リソースの特性をチェックして帯域の節約をはかるのに有用である。ファイルのコンテンツを必要としない場合には、HEADを使用すること。
HEAD要求に対する応答メッセージには決して本体を含めてはならず、ステータス行とヘッダ行（0個以上）とからだけからなる。
POSTメソッド
POST要求は、CGIスクリプトのように、なんらかの手段でサーバ側にて処理すべきデータを送出するときに使用する。POST要求のGET要求との相違点は以下のとおり。
- 要求とともにデータの集まりをメッセージ本体に入れる。そのために通常メッセージ本体を記述するヘッダ、例えばContent-Type:やContent-Length:などのヘッダが追加されている。
- 要求URIは検索すべきリソースを意味するのではなく、通常、送出中のデータが処理されるべきプログラムを指定する。
- HTTP応答はプログラムからの出力であり、静的なファイルではない。
最も一般的なPOSTの使用法は、HTMLフォームのデータをサーブレットやCGIスクリプトに提出することである。この場合、Content-Type:ヘッダは通常application/x-www-form-urlencodedとなり、Content-Length:ヘッダはURLエンコードされたフォームデータのバイト長となる。CGIの場合はこのメッセージ本体をSTDIN経由で受領し、デコードする。以下にPOSTによる典型的なフォームデータ提出（submission）例を示す。
POST /path/script.cgi HTTP/1.0
From: terry@cresc.co.jp
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
Home=Cosby&faborite+flavor=flies
POST要求は、フォームデータの送信に限ったものではなく、送りたいと思うデータは何であれ送ることが出来る。ただし受け取る側のプログラムは、ちゃんとそのデータに対応できていることが必要である。GETメソッドも実はフォームを提出する事ができる。この場合、フォームデータはURLエンコードされ、要求URIに追加される。（RFC 2396, section 2.4参照）しかしこれは長いURIとなってしまうので、大量のフォームデータを送出するのには適さない。
Servletによるサービスプログラムを作成する場合は、ブラウザからのフォームデータつきPOST要求メッセージのフォーマットを十分理解しておく必要があろう。
付章1-4 HTTPプロキシ
HTTPプロキシは、クライアントとサーバ間に介在する。HTTPプロキシは、クライアントからの要求メッセージを受信すると、これを目的とするサーバに転送する。サーバからの応答メッセージの戻りパスにおいても同様である。従ってプロキシはサーバとクライアントの双方の機能を兼ね備えていると云える。
プロキシの目的はファイアウオール、キャッシュなどである。プロキシは、HTTPバージョンも含めてクライアント／サーバ間のTCP接続状態を正しく監視・管理していなければならない。
クライアントがプロキシを使用しているときは、全要求メッセージをURLに示されたサーバではなく、該プロキシに送信する。プロキシに送信する要求メッセージと通常の要求メッセージとの相違はただひとつ、最初の行の部分で、単なるパスではなく、要求するリソースの完全なURLが使われることである。例えば：
GET http://www.my-host.cresc.co.jp/path/file.html HTTP/1.0
これにより、プロキシはこの要求メッセージを転送すべきサーバを知ることが出来る。
付章1-5 相手に対して寛容であること
「自分が送信するものには厳格であれ、反対に受信するものに対しては寛容であれ」ということが重要である。自分がインタラクトするクライアントやサーバが出すメッセージにはわずかな不備が存在するかも知れないが、それにうまく対応すべきである。特にHTTP仕様書では、以下の事項を推奨している。
- ヘッダ行はCRLFで終端しなければならないことになっているものの、LFのみしか出さないものもある。従ってCRLFとLFの双方を受け付けるようにしたほうが良い。
- 初期メッセージ行の各要素は単一のスペースで分離することになっているが、ものによっては複数のスペースやタブを出すものもあるので、各フィールド間は複数のスペースやタブを許容するようにしたほうが好ましい。
HTTP仕様書には、種々の日付のフォーマットにも対応するようにとかその他の推奨事項が記されているのでそちら(RFC 2616 Section 19.3, “Tolerant Applications”)を参照されたい。
付章1-6 HTTP 1.1(RFC 2616)の改良点
HTTP 1.1 は、HTTP 1.0のスーパーセットであり、主たる改良点は以下のようである。
- 単一の継続したTCP接続上での複数のトランザクションを許容しているので応答が早い
- キャッシュのサポートが追加されているので、高速かつ帯域節約となっている
- 塊としてのエンコーディング(Chunked Encoding)をサポートしており、全体のバイト長を知る前に応答を送信できるので、ダイナミックに作成されるページを高速にかえすことができる
- 単一のIPアドレスで、サービスする複数のドメインを指定できるので、IPアドレスを効率的に使うことが出来る。
HTTP 1.1ではクライアント、サーバ双方に幾つかの必要事項が付加されている。以下の節でクライアント、サーバをHTTP 1.1対応とするための事項を記述する。
RFC 2616にはそれ以外の多くの機能が記述されているので、より詳しく知りたい読者はそちらを参照されたい。
1-6.1 HTTP 1.1クライアント
HTTP 1.1対応であるためには、クライアントは以下の事項が必要である。
- 各要求にHost:ヘッダを含めること
- chunkedデータを受理できること
- 継続したTCPコネクション対応となっているか、各要求にすべてConnection: closeなるヘッダを挿入すること
- 100 Continue応答が処理できること
Host:ヘッダ
HTTP 1.1でセッションを介しする場合、ひとつのIPアドレスをもつひとつのサーバは、複数のホーム、言い換えれば複数のWebのドメインを持ち得る。例えば、www.host1.co.jp及びwww.host2.co.jpが同一のサーバに存在し得る。
同じサーバ上に複数のドメインが存在するということは、ひとつの電話を複数の人が共用する場合と類似している。相手側はかけた相手を識別することは出来ても、誰が電話をとってくれるか知ることができない。従って各HTTP要求は、該要求が意図する相手のホスト名をHost:ヘッダで指定してやらねばならない。完全なHTTP要求は以下のようになる。
GET /path/file.html HTTP/1.1
Host: www.host1.co.jp:80
空白行
ここでポートを指定する:80は必ずしも必要としない。ポート番号80は、HTTPのデフォルトポートである。Host:はHTTP 1.1でのみ必要かつ必須なヘッダ行であるので注意のこと。これがないと、各ホスト名は各々に別々のIPアドレスが必要となり、インターネットの拡大により急速にIPアドレスを使い切ってしまう危険性がでる。
厚切りエンコーディング(Chunked Transfer-Encoding)
サーバが応答全体の長さを知る前に応答の送信を開始したい場合には、以下に示す簡単な厚切りエンコーディングを適用する。これは応答の全部を厚切りに分割して、それのシリーズとして送ってしまうやりかたである。応答メッセージに次のようなヘッダが含まれていれば、それは厚切りエンコーディングである。
Transfer-Encoding: chunked
全てのHTTP 1.1対応クライアントは、このエンコーディングを受理できなければならない。
厚切り形式のメッセージ本体は、厚切りの連続で、終了行としての”0”（ゼロ）を含む行と、それに続くオプショナルなフッタと空白行からなる。各厚切りデータは、次の２つの要素からなる。
- 厚切りデータのサイズを１６進で示す行。行の終了のためのCRLFの前に”;”（セミコロン）に続くパラメータを挿入しても構わないが、これらのパラメータをブラウザは無視する。
- データ自身で、CRLFで終端される。
厚切りデータの応答例を示す
HTTP/1.1 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
1a; ignore-stuff-here
abcdefghijklmnopqrstuvwxyz
10
1234567890abcdef
0
some-footer: some-value
another-footer: another-value
空白行
最後のフッタの後に空白行が必要なことに注意されたい。テキストデータ全体は”abcdefghijklmnopqrstuvwxyz1234567890abcdef”であり、そのバイト長は１０進で42（16進の1a+10）である。フッタは、あたかもそれが本体の前のヘッダ部分にあるごとく、ヘッダと同じように処理されなければならない。
厚切りデータにはどのようなバイナリデータを含めても構わないし、この例よりもっと長くても構わない。サイズに続けたパラメータは滅多には使用されないが、これはきちんと無視されなければならない。フッタもまたあまり使用されないが、チェックサムやデジタル署名には適切かもしれない。
比較のために、厚切りエンコーディングを使用しない場合の全事例と等価な応答メッセージを示す：
HTTP/1.1 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/plain
Content-Length: 42
some-footer: some-value
another-footer: another-value
abcdefghijklmnopqrstuvwxyz1234567890abcdef
空白行
継続した接続(Persistent Connection)と”Connection: close”ヘッダ
HTTP 1.0では、各要求／応答が終了するたびにTCP接続が終了する、つまり検索する各リソース毎にTCP接続が必要であった。TCPの接続と解放には相当なCPU時間、帯域、メモリを必要とする。現実は、殆どのWebページは同一サーバ上の複数のファイルからなり、単一の継続したTCP接続のまま複数の要求／応答を許容すれば多大な節約が可能になる。
継続した接続はHTTP 1.1ではデフォルトとなっており、これを使うために特別必要とするものはない。単に接続をオープンとして、複数の要求を直列に（パイプライン化するという）送信し、送信したと同じ順序で応答を読み出せば良い。そのためには、クライアント側は各応答の正確なバイト長を読みとり、各応答を正しく分離することに注意しなければならない。
もしクライアントがその要求メッセージに”Connection: close”なるヘッダを含めた場合には、それに対応した応答の直後に接続が解放される。継続した接続をサポートしない系の場合、あるいはその要求が該接続の最後であることがクライアント側で分かった場合には、必ずこのヘッダを挿入しなければならない。同様に、応答にこのヘッダが含まれていた場合には、該応答の後にサーバは接続を解放するので、クライアントは該接続でそののちに要求メッセージを送出してはならない。
サーバは、全ての応答が送られてしまう前に接続を切ってしまう場合があるかもしれない。そのときのため、クライアントは自分が出した要求と応答をきちんと追跡して、不足があれば要求を再送出する。再送の際は、接続が「継続」であることを確認するまでは要求をパイプライン化してはならない。サーバが継続した接続をサポートしていない（HTTP 1.0のように）ことが分かったら絶対パイプライン化してはならない。
“100
Continue”応答
HTTP 1.1クライアントがサーバに要求を送信している途中で、サーバは途中に100 Continue”応答をかえしても良い。これは、該サーバが要求の最初の部分を受信し、低速のリンク経由での通信が継続してできていることを意味する。いづれにしても、HTTP 1.1クライアントはこの100応答を正しく処理（たぶん単に無視し、該要求を継続して送出するだけ。すでに該要求を送出してしまっている場合は単に無視するだけ）できなければならない。
さきに示し応答例にこの応答が加わった場合は次のようになろう。
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/plain
Content-Length: 42
some-footer: some-value
another-footer: another-value
abcdefghijklmnopqrstuvwxyz1234567890abcdef
空白行
1-6.2 HTTP 1.1サーバ
サーバがHTTP 1.1であるための必須事項は以下のとおり：
- HTTP 1.1クライアントからHost: ヘッダを要求する
- 要求メッセージ中の絶対URLを受理する
- 厚切りデータ形式の要求メッセージを受理する
- 継続した接続に対応するか、または応答毎に”Connection: close”ヘッダを挿入する
- “100 Continue”応答を適切に送出できる
- 各応答にDate: ヘッダを挿入する
- If-Modified-Since: またはIf-Unmodified-Since: ヘッダつきの要求を処理できる
- 少なくともGETとHEADメソッドに対応できる
- HTTP 1.0要求に対応する
Host:
ヘッダの要求
HTTP 1.1サーバは、Host: ヘッダなしの要求には寛大ではあり得ない。そのような要求メッセージを受信したら、サーバは以下のように”400 Bad Request”応答をかえさなければならない。
HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 111
<html><body>
<h2>No Host: header received</h2>
HTTP 1.1 requests must include the Host: header.
</body></html>
空白行
この要求はを使っているクライアントにのみ適用され、将来のHTTPバージョンには適用されないことに注意にこと。1.1以降のHTTPバージョンを使う場合は、Host:ヘッダの代わりにサーバは絶対URLを受理できる。（次節参照）要求メッセージがHTTP/1.0を使用しているときは、ホストの識別なしで該要求を受理して良い。
絶対URLの受理
Host:ヘッダは、実のところホスト識別の問題の過渡的なソリューションであり、HTTPの将来のバージョンでは、要求は以下の事例のようにパス名でなく絶対URLを使用することになろう。
GET http://www.somehost.co.jp/path/file.html HTTP/1.2
バージョンの移行を容易とするため、HTTP 1.1サーバは、HTTP 1.1クライアントがこれを送信していなくてもこの形式の要求を受理できるようにしていなければならない。サーバは、HTTP 1.1クライアントがHost:ヘッダなしで要求メッセージを送出したときは、前節に記したとおりエラーを報告しなければならない。
厚切り転送エンコーディング
HTTP 1.1クライアントがこの形式の応答を受理できなければならないのと全く同様に、HTTP 1.1サーバは厚切り形式の要求メッセージを受理できなければならない。サーバはこの形式のデータの発生を要求されてはいないが、この形式のデータの受信は出来なければならない。
継続した接続と”Connection: close”ヘッダ
HTTP 1.1クライアントが単一の接続下で複数の要求を送出している場合、サーバは同じ順序で応答を送り返しさねばならない。これが継続接続対応のサーバがすべきことのすべてである。
要求メッセージのなかに”Connection: close”ヘッダが含まれている場合は、該要求は該接続における最後の要求であることを示し、対応する応答メッセージを送出し終わったら該接続を終了させねばならない。また、サーバはある一定時間（どのような値でも良いが１０秒あたりが良い）でタイムアウトした待ち状態の接続があれば、これを終了させねばならない。
継続接続に対応したくなければ、応答メッセージに”Connection: close”ヘッダを含めればよい。全ての要求に対して応答してはいなくても、接続を解放したいと思えばいつでもこれを使用して良い。このヘッダの意味するところは、現在の応答の後は接続が解放されるということであり、HTTP 1.1クライアントはこれを正しく処理しなければならない。
“100
Continue”応答の使用
HTTP 1.1クライアントの節で説明したとおり、この応答は低速リンクでの対応の助けとするものである。
HTTP 1.1サーバがHTTP 1.1（またはそれ以降）要求の最初メッセージの行を受信したら、“100 Continue”応答またはエラーメッセージで対応しなければならない。“100 Continue”応答をかえすときは、そのあと該要求を処理されたときに、最終的な応答を送出しなければならない。“100 Continue”応答はヘッダなしであるが、通常の空白行を以下のように伴っていなければならない。
HTTP/1.1 100 Continue
空白行
他のHTTP応答メッセージがここに入る
“100 Continue”応答をHTTP 1.0クライアントに送ってはいけない。HTTP 1.0クライアントはこれをどう処理すべきかを知ってはいない為である。
Date:ヘッダ
キャッシングはHTTP 1.1の大きな改良点であるが、タイムスタンプされた応答なしでは機能しない。従って、サーバは各応答メッセージに必ず以下に示すDate:ヘッダにより現在時刻を挿入しなくてはいけない。
Date: Fri, 31 Dec 1999 23:59:59 GMT
100レベルの状態応答以外（但しエラー応答には必要）の総ての応答メッセージにDate:ヘッダを含めること。HTTPでは総ての時刻にGMT(Greenwich Mean Time)を使用する。
If-Modified-Since:
とIf-Unmodified-Since:ヘッダつき要求の処理
送ってもらいたくないリソースの送信を避け、それにより帯域の節約を図る為に、HTTP 1.1ではIf-Modified-Since: とIf-Unmodified-Since:の要求ヘッダを定義している。前者は、「この時刻以降に変更がなされているリソースのみを送って欲しい」という意味であり、後者はその逆である。クライアント側は必ずこれを使用するよう要求されてはいないが、HTTP 1.1サーバはこれらを使用した要求メッセージを受理することは必要である。
残念ながら、初期のHTTPバージョンのからみで、3種類の日付の書式が存在し得るので、この総てに対応できなければならない。
If-Modified-Since: Fri, 31 Dec 1999 23:59:59 GMT (RFC 822, 1123)
If-Modified-Since: Friday, 31-Dec-99 23:59:59 GMT (RFC 850)
If-Modified-Since: Fri Dec 31 23:59:59 1999 (asctime() in ANSI)
HTTPでは、時刻情報はGMTを使用しているが、非GMT時刻にも寛容であることも必要かもしれない。年のフィールドが2桁の場合は、50以上／以下で西暦を判断する。（いわゆる2000年問題）
HTTP 1.1サーバは、この3形式の総てに対応するが、HTTP 1.1クライアントは必ず最初の書式のみを使用する。
これらの総ての書式に有効でない時刻、あるいは有効であっても将来時刻の場合はそのヘッダは無視される。
このヘッダがない場合は、該要求は不成功（非200レベル）のステータスコードを発生させることになる。言いかえれば、でなければ該リソースが送られてしまうことが判った時点でこれらのヘッダを適用する。
If-Modified-Since:ヘッダは、GET要求に使われる。指定された時刻以降に該リソースが変更されているときは、該ヘッダを無視し、そのリソースを通常と同じように応答する。そうでない時は、Date:ヘッダをつけ、本体なしで”304 Not Modified”応答をかえす。
HTTP/1.1 304 Not Modified
Date: Fri, 10 Feb 2000 23:59:59 GMT
空白行
If-Unmodified-Since:ヘッダにおいても同様であるが、どのメソッドとともにでも使用される。該リソースが指定されている時刻以降変更されていなければ該ヘッダを無視し、通常と同じようにそのリソースを返す。そうでない時は”412 Precondition Failed”応答を返す。
HTTP/1.1 412 Precondition Failed
空白行
GET及びHEADメソッド対応
HTTP 1.1対応サーバは、少なくともGETとHEADメソッドに対応していなければならない。GCIスクリプトやサーブレットの場合は、POSTメソッドも対応することが必要である。
HTTP 1.1では多くのメソッドが定義されているが、上記のメソッド以外はあまり使われてはいない。サーバが対応していないメソッドでクライアントが要求してきた場合には、”501 Not Implemented”で応答する。
HTTP/1.1 501 Not Implemented
空白行
HTTP
1.1要求の対応
古いブラウザとの両立性を保つ為に、HTTP 1.1サーバはHTTP 1.0要求に対応しなければならない。とりわけ、要求がHTTP 1.0を使用している場合は、（初期要求行で識別されているように）
- Host:ヘッダを要求してはいけない、そして、
- 100 Continue応答を返してはならない。