Hypertext Transfer Protocol
| TCP/IP群 | |
|---|---|
| アプリケーション層 | |
|
BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP カテゴリ |
|
| トランスポート層 | |
|
TCP / UDP / DCCP / SCTP / RSVP / ECN カテゴリ |
|
| ネットワーク層 | |
|
IP (IPv4, IPv6) / ICMP / ICMPv6 / IGMP / IPsec カテゴリ |
|
| リンク層 | |
|
ARP/InARP / NDP / OSPF / トンネリング (L2TP) / PPP / MAC (イーサネット, IEEE 802.11, DSL, ISDN, FDDI) カテゴリ |
HyperText Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、略称 HTTP）とは、WebブラウザとWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコルである。RFC 2616で規定されている。ハイパーテキスト転送プロトコルとも呼ばれる。
目次 |
[編集] 概要
HTTP は HTML (HyperText Markup Language) や XML (Extensible Markup Language) によって記述されたハイパーテキストを転送することを主な目的としているが、転送する内容はハイパーテキストに限らず画像、音声などのバイナリデータも含め様々なデータを送ることができる。
HTTPはリクエスト-レスポンス型のプロトコルである。すなわち、クライアントがサーバにリクエストメッセージを送信し、サーバがこれにレスポンスメッセージを返す。レスポンスメッセージを返した時点で基本的にサーバは初期状態に戻る。つまり、サーバがクライアントの状態を保存しない。HTTP においてはトランスポート・プロトコルとして通常TCPを使用する。
基本的な考え方は非常に単純であり「何を」「どうして」ほしいのかを相手に要求する。「何を」に当たるのがURL、「どうして」がメソッドにあたる。
World Wide WebにおけるWebページなどのリソースは、Uniform Resource Identifierによって指定される。HTTP を使用してリソースにアクセスするときは、http: が先頭についた URL を使用する。URL の例をあげる。
http://www.example.co.jp/~test/samples/index.html
最初、HTTP/0.9ではURLのみの簡単なやりとりであったが、HTTP/1.0でNNTPやSMTPのような各種ヘッダが定義され、HTTP cookieなどの利用が可能になった。HTTP/1.1では複数データを転送するためのキープアライブ（keep-alive）機能やプロキシなどの利用も想定された仕様になった。
このほかの点を箇条書きで示す。
- ポート番号80をデフォルトとして使用する（送信時は8080）。
- TLSで暗号化され、セキュリティを確保したHTTPは、HTTPSと呼ばれる（httpsは実際にはURIスキームの1つであり、実際のプロトコルにはHTTP over SSL/TLSが用いられる）。
- HTTP は基本的にサーバが状態を保持しない (stateless) プロトコルだが、データベースなどを使用するWebアプリケーションにおいては状態保持が必要だったため、そのためにいわゆる Cookie とよばれる機構が Netscape Communications Corporation によって導入された。Cookie を使用することによって状態を管理し、"セッション" を維持することが可能になる。
- HTTPの拡張プロトコルとしてWebDAVがある。
- UPnPでは、HTTPをUDP上で使用するHTTPUや、マルチキャストで使用するHTTPMUが規定された。
[編集] 歴史
イギリスの物理学者ティム・バーナーズ＝リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。
以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。
最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントであったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量にふくれあがった。
[編集] HTTP/1.1
バーチャルホストをサポートした。インターネット人気に伴い多くの企業がWebサイトを持ち始めたが、当時ではまだまだ企業が自前のWebサーバを運用するのは人員、効率の問題で難しかったためISPのサーバでホスティングをしていた。当時はまだ一社ごとに専用サーバを用意するほどのことでもないため一台のサーバで複数のWebサイトを運用していた。
しかしバーチャルホストには問題がある。例えばある1台のサーバに foo.example.com と bar.example.com という二つの仮想Webサーバがあるとする。ここではクライアントは http://foo.example.com/index.html にアクセスしたいとする。そのためにはまず foo.example.com をIPアドレスに解決するためDNSサーバに問い合わせ、そのサーバにアクセスし GET index.html を要求する。しかしサーバ側のIPアドレスは foo.example.com と bar.example.com 共におなじIPアドレスである。もし foo.example.com にも bar.example.com にも index.html というファイルが存在すればクライアントはどちらのサーバにアクセスしたのかわかるすべがない。
これを解決するにはそれぞれにIPアドレスを付与することで解決できるが、IPv4の資源を無駄にすることになる。
HTTP/1.1ではこれを解決するためにHostヘッダを追加した。
- HTTP/1.0のヘッダ
-
GET /index.html HTTP/1.0
- HTTP/1.1のヘッダ
-
GET /index.html HTTP/1.1 Host: foo.example.com
[編集] 動作
[編集] 通信の開始
他のプロトコル同様クライアント側とサーバ側ではHTTPの役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。
クライアント側はサーバにリクエストを送り、サーバはクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。
[編集] 接続
システム間でメッセージをやりとりするにはTCP接続を確立させる必要がある。
HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があったが、これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきているが、これら全てのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、HTTP/1.1では持続的接続がサポートされることとなった。ただしこの機能が利用できるのはサーバ側がその要求を許可した場合のみである。
[編集] パイプライン
クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。
[編集] メソッド
HTTPでは8つのメソッドが定義されている。ただし実際のHTTP通信ではGETとPOSTメソッドだけで殆どを占める。
| メソッド | HTTP/0.9 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|---|
| GET | ○ | ○ | ○ |
| POST | ○ | ○ | |
| PUT | △ | ○ | |
| HEAD | ○ | ○ | |
| DELETE | △ | ○ | |
| OPTION | ○ | ||
| TRACE | ○ | ||
| CONNECT | ○ |
- GET
- 指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。
- POST
- GETとは反対にクライアントがサーバにデータを送信するメソッドである。Webフォームや電子掲示板、Wikiなどに投稿する。GETの場合と同じくサーバはクライアントにデータを返すことができる。
- PUT
- 指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。
- DELETE
- 指定したURIのリソースを削除する。
- OPTION
- サーバを調査するメソッド。例えばサーバがサポートしているHTTPのバージョンなどを調査できる。
- HEAD
- GETと似ているがサーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることが出来る。例えばWebページのリンク先が生きているか検証するときなどにリンク先のデータを全て取得することなく調査することが出来る。
- TRACE
- サーバまでのネットワーク経路をチェックできる。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。
- CONNECT
- 暗号化したメッセージをプロキシで転送する際に用いる。
[編集] サーバの連携
[編集] バーチャルホスト
上記参照
[編集] リダイレクト
301 MovedというステータスコードとURIを受け取りクライアントはこの受け取ったURIに再度GETを送る。
[編集] クッキー
詳細は「HTTP cookie」を参照
[編集] HTTPメッセージ
クライアントからのHTTPリクエストは3つの要素から構成される。それぞれメソッド、URI、HTTPのバージョンでありスペースで区切られている。 下にもっとも単純な、クライアントとサーバ(www.google.co.jp:80)とのHTTPプロトコルのやり取りの例を挙げる。
クライアントのリクエスト:
GET / HTTP/1.0
GETがメソッド、URIは / 、バージョンはHTTP/1.0であることを示す。
URIは/でルートリソースを対象にしたリクエストであることを示している。TRACEなど特定のサーバを対象としないリクエストの場合には*が表示される。
サーバのレスポンス:
HTTP/1.0 200 OK Cache-Control: private Content-Type: text/html Set-Cookie: PREF=ID=72c1ca72230dea65:LD=ja:TM=1113132863:LM=1113132863:S=nNO7MIp W2o7Cqeu_; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.co.jp Server: GWS/2.1 Date: Sun, 10 Apr 2005 11:34:23 GMT Connection: Close <html><head><meta http-equiv="content-type" content="text/html; charset=Shift_JI S"><title>Google</title><style><!-- ・・・以下省略
上のリクエストのGETにあたる部分をメソッドといい、 HTTP/1.0では、GET, HEAD, PUT, POST, DELETE, LINK, UNLINK、 HTTP/1.1ではさらに、OPTIONS, TRACEがある。 GETメソッドのレスポンスにはヘッダ情報のあとに改行が挟まれ、コンテンツ本体が送られる。 HEADメソッドのレスポンスにはコンテンツサイズや更新日時などの情報を含むヘッダのみが送られる。
また、リクエストの2行目以降はヘッダを送る。
[編集] HTTPヘッダフィールド
ヘッダの各要素は
フィールド名: 内容
のペアで構成される。
ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。
なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0では無くても良い。 但し、サーバがバーチャルホストを利用している場合は、Hostヘッダが無いとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。
[編集] HTTPヘッダフィールドの一覧
| ヘッダ | 概要 | HTTP/0.9 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|---|---|
| Accept | クライアントの受け入れ可能コンテンツタイプを示す | ○ | ○ | |
| Accept-Charset | クライアントの受け入れ可能文字セットを示す | ○ | ○ | |
| Accept-Encoding | クライアントの受け入れ可能文字エンコーディングを示す | ○ | ○ | |
| Accept-Language | クライアントの受け入れ可能言語を示す | ○ | ○ | |
| Authorization | クライアントの認証情報を示す | ○ | ○ | |
| Cookie | クライアントの状態管理情報をサーバに返す | |||
| Cookie2 | HTTP/1.1のSet-Cookie2ヘッダの受け入れ可能をサーバに知らせる | |||
| Expect | クライアントがサーバに期待する動作を示す | ○ | ||
| From | リクエスト発行者個人の情報を示す。一般的に電子メールアドレスを使用する | ○ | ○ | |
| Host | 要求しているオブジェクトがあるホストを示す | ○ | ||
| If-Match | if文を用い条件が真の場合のみリクエストを処理するようサーバに要求する | ○ | ||
| If-Modified-Since | 指定日及び指定時刻以降にオブジェクトが変更されている場合のみリクエストを処理するよう要求する | ○ | ○ | |
| If-None-Match | If-Matchの逆で条件が真でない場合のみリクエストを処理する要求 | ○ | ||
| If-Range | 条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する | ○ | ||
| If-Unmodified-Since | If-Modified-Sinceの逆で真でないときのみ実行する | ○ | ||
| Max-Forwards | リクエストの中間システム経由数を最大いくつまでかを指定する | ○ | ||
| Proxy-Authorization | クライアントがプロキシサーバに対して自身の認証を行う | ○ | ||
| Range | オブジェクト全体でなくリソースの一部を要求する | ○ | ||
| Referer | リクエストの出所を示す。一般的にはユーザの辿ったWebページのURLが用いられる。 | ○ | ○ | |
| TE | レスポンスの受け入れ可能転送エンコーディングを示す | ○ |
| ヘッダ | 概要 | HTTP/0.9 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|---|---|
| Accept-Ranges | オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す | ○ | ||
| Age | オブジェクトの経過時間を秒単位で返す | ○ | ||
| Allow | オブジェクトがサポートするHTTPメソッドを示す | ○ | ○ | |
| ETag | オブジェクトのエンティティタグ値を示す | ○ | ||
| Location | オブジェクトの場所を示す | ○ | ○ | |
| Proxy-Authenticate | プロキシサーバがクライアントに認証を要求するときに用いる | ○ | ||
| Retry-After | リクエストの再試行をいつ行うかをクライアントに通知する | ○ | ○ | |
| Server | サーバのベンダー名、バージョン番号を示す | ○ | ○ | |
| Set-Cookie2 | サーバがクライアントにCookieを送信するときに用いる | |||
| Vary | サーバのレスポンス内容を決定する際にリクエストURI以外に使用したHTTPヘッダのリストを示す | ○ | ||
| WWW-Authenticate | クライアントに対してリクエストの再発行を要求する。認証情報も含まれる | ○ | ○ |
| ヘッダ | 概要 | HTTP/0.9 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|---|---|
| Cache-Control | メッセージの経由する中間キャッシュの動作を指示する | ○ | ||
| Connection | 中間システムが転送すべきでないヘッダのリストを示す | ○ | ○ | |
| Date | メッセージの作成日時を示す | ○ | ○ | |
| Pragma | メッセージに関する追加情報を示す | ○ | ○ | |
| Trailer | メッセージボディの後に追加のヘッダーが表れることを示す | ○ | ||
| Transfer-Encoding | クライアントの転送を目的としたオブジェクトのエンコーディングを示す | ○ | ||
| Upgrade | 通信相手に別のプロトコルにアップデートするよう要求する | ○ | ||
| User-Agent | クライアントのWebブラウザなどの情報を示す | ○ | ○ | |
| Warning | メッセージに関する追加情報を示す。通常はキャッシュの問題を警告するときに使われる | ○ |
| ヘッダ | 概要 | HTTP/0.9 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|---|---|
| Content-Encoding | オブジェクトのエンコーディングを示す | ○ | ○ | |
| Content-Language | オブジェクトの言語（人間の言語）を示す | ○ | ○ | |
| Content-Length | オブジェクトのサイズをバイト単位で示す | ○ | ○ | |
| Content-Location | オブジェクトの場所を示す | ○ | ||
| Content-MD5 | オブジェクトのメッセージダイジェストを運ぶ | ○ | ||
| Content-Range | メッセージボディで運ばれるオブジェクトの範囲を示す | ○ | ||
| Content-Type | オブジェクトのタイプを示す | ○ | ○ | |
| Expires | オブジェクトの有効期限の日時を示す | ○ | ○ | |
| Last-Modified | オブジェクトが最後に変更された日時を示す | ○ | ○ |
- Accept
- サーバのレスポンスに含まれるメッセージボディで受け入れることが出来るコンテンツタイプと各コンテンツタイプの相対的な優先度を指定するリクエストヘッダ。指定できるコンテンツタイプはIANAによって定義されている。
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
- 上記のようにAcceptヘッダには行をわけて複数のコンテンツタイプを指定できる。上記の例はいずれの4のコンテンツタイプのいずれも受け入れ可能であることを示す。0.5や0.8といった数字は品質係数で0～1の範囲の数値である。数値の指定がなければ1.0となる。
- text/plain; q=0.5
- text/html
- text/x-dvi; q=0.8
- text/x-c
- Accept-Charset
- レスポンスで返されるメッセージボディの文字コードを指定するリクエストヘッダ。Acceptと同じく複数指定でき品質係数も設定できる。定義済み文字セットはIANAが管理している。
Accept-Charset: unicode, *; q=0.8
- この例だとクライアントはUnicode文字セットを優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている。ただしサーバからのレスポンスのHTTPヘッダそのものの文字コードは常にISO-8859-1である。
- Accept-Encoding
- Accept-Language
- レスポンスの言語（人間の言語）に対する優先度を指定する。言語コードはISO-639の2文字の省略コードを用いる。書き方は他のAccept-群と変わらず。
Accept-Language: en-gb, en; q=0.8
- 上記の例はまずイギリス英語を要求し、利用できない場合はその他の英語を要求する。
- Accept-Ranges
- Acceptで始まる他のヘッダフィールドと違いレスポンスヘッダーである。現在の仕様では2つの指定方法しかない。
- Age
- リソースの推定経過時間を表示するレスポンスヘッダ。キャッシュサーバーはAgeヘッダの値からキャッシュしたリソースが有効かどうかを判定する。
- Allow
- Authentication-info
- ユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダー。
- Authorization
- サーバに対するクライアント自身の認証を行うことが出来る。
- Cache-Control
- キャッシングの動作を指定するためのマスターヘッダ。
- Connection
- Content-Encoding
- Content-Language
- リソースを英語などの自然言語で示すのに使われる。言語の指定はAccept-Languageヘッダと同じ。
- Content-Length
- Content-Location
- Content-MD5
- メッセージボディが変更されず宛先に届くことを保証する。MD5アルゴリズムを実行する。ただし悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない。どちらかといえば偶発的な変更の保証をしている。
- Content-Range
- ダウンロードの再開に用いられる。
- Content-Type
- メッセージボディに含まれるオブジェクトタイプを示す。次の例はリソースがテキストファイル、文字セットはISO-8859-4を使用していることを示している。
Content-Type: text/plain; Charset=ISO-8859-4
- Cookie
-
詳細は「HTTP cookie」を参照
- クライアントがHTTP状態管理を望む場合にサーバから受け取ったクッキーを以後のリクエストに次の例のようなヘッダーを付加する。
Cookie: $Version="1"; NAME="VALUE";
$Path="/shopping"; $domain="www.shop.com"+
$Port="80"
- $VersionはHTTPのバージョン、NAMEはクッキーの名前である。$から始まるクッキー名は使用が禁止されている。
- Cookie2
- 基本的にCookieヘッダーとCookie2ヘッダーは別物である。
- Date
- サーバがメッセージを生成した日時を示す。リソースの時間を示すLast-Modifiedヘッダーとは区別する必要がある。
- HTTP/1.1では次のような形式を用いるようRFC1123で定義されている。
Date: Sun, 06, Nov 1994 08:49:37 GMT
- HTTP仕様ではレスポンスに
Dateヘッダーを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダーは返らない。
- ETag
- 主にキャッシングのパフォーマンスを向上する目的で使われる。
- Expect
- サーバに対して特定の動作の期待を知らせる。用途としてはクライアントがサーバに対して100 Continueステータスを返すことを期待する場合に使われる。
Expect: 100-continue
- サーバが期待に応じれない場合は417 Expectation Failedを返す。クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない。
- Expires
- オブジェクトの有効期限を示す。このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことが出来る。サーバがオブジェクトのキャッシュを望まない場合には
Expiresヘッダに過去の日時を設定することが多い。また、HTTP仕様では1年以上先の日時は設定できない。
Expires: Thu, 28 Aug 2010 16:00:00 GMT
Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。
- From
- リクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。
From: hoge@hogehoge.com
- Host
- 主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合レンタルサーバのウェブサイトとまともな通信が出来ないと言ってよい（詳細はHTTP#歴史を参照）。
- If-Match
- クライアントのリクエストを条件付きのリクエストにするために使われる。サーバは一定の条件が真であった場合のみリクエストを受け入れることが出来る。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。
「if文」も参照
- 利用者：HogeがHTTPの記事を取得。
ETagは1234 - 利用者：HageがHTTPの記事を取得。
ETagは1234 - 利用者：HogeがHTTPの
ETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。 - 利用者：HogeがHTTPの記事を編集。
ETagは1256になる。 - 利用者：HageがHTTPのETagを再度取得。先ほど取得した
ETagと現在のETagはマッチせず。 - サーバは利用者：Hageの書き込みを拒否。
- If-Modified-Since
- このヘッダーで指定された日時以降にオブジェクトが変更されている場合のみリクエストに応答するようサーバに要求する。リソースの削減に効果がある。
- If-None-Match
If-Matchと逆で条件が真でない場合のみリクエストを処理するよう要求する。
- If-Range
- クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。
- If-Unmodified-Since
If-Modified-Sinceの逆の働きをする
Last-Modifiedサーバオブジェクトの最終更新日時を示す。クライアントはこのヘッダを利用しIf-Modified-Sinceヘッダ等と組み合わせることによって効果を発揮する。
- Location
- サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Createdのレスポンスでも使うことが出来る。
Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。
- Max-Forwards
- プロキシサーバ等を経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、
OPTIONメソッドやTRACEメソッドと共に用いられる。
[編集] HTTPステータスコード
ステータスコードはクライアントのリクエストが成功したかどうかを示した上で追加情報を提供するいずれも3桁の数字から成る。具体的には100-199が情報提供、200-299が成功を示す。300-399はリダイレクト、400-499はエラーを示す。
詳細は「HTTPステータスコード」を参照
[編集] セキュリティ技術
[編集] Basic認証
HTTP/1.1でBasic認証が定義されており最も単純なセキュリティ技術である。しかし仕様書を読むと定義を書いた著者自身が認証技術に疎いことがよくわかる。『HTTPプロトコル セキュア＆スケーラブルなWeb開発』の著者は「基本認証を用いるくらいならなにも使わない方がまし」と著書に書いている。通常サーバは401ステータスコードで応答する。
詳細は「Basic認証」を参照
[編集] Digest認証
詳細は「Digest認証」を参照
[編集] その他
- 行末文字はWindowsと同じCRLF。
[編集] 関連項目
- HTTPステータスコード
- FTP
- WebDAV
- Webサーバ
- ウェブブラウザ
- アプリケーションサーバ
- REST
- HTTPヘッダ・インジェクション
- Hyper Text Coffee Pot Control Protocol
- バーチャルホスト
[編集] 外部リンク
- RFC 2818 - HTTP Over TLS
- RFC 2817 - Upgrading to TLS Within HTTP/1.1
- RFC 2616 - HTTP/1.1
- RFC 2068 - HTTP/1.1（初版，RFC 2616 によって obsolete）
- TS X 0085:2004 - ハイパテキスト転送プロトコル HTTP/1.1 標準仕様書(TS)
- RFC 1945 - HTTP/1.0
- HttpTea Freeware HTTP Logger
- Studying HTTP
 |
この「Hypertext Transfer Protocol」はコンピュータに関連した書きかけ項目です。この記事を加筆して下さる協力者を求めています（PJ コンピュータ / Portal:コンピュータ）。 |
