HTTP

英

hypertext transfer protocol

参考

• HTTPエラー

http://www.bmoo.net/archives/httperrors

Wikipedia preview

出典(authority):フリー百科事典『ウィキペディア（Wikipedia）』「2016/01/15 06:16:41」(JST)

wiki ja

[Wiki ja表示]

HTTP
主要項目 Persistence Compression HTTPS HTTP/2
ヘッダーフィールド Cookie ETag Location Referer DNT X-Forwarded-For
ステータスコード 301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found 451 Legal Reasons 503 Service Unavailable

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 カテゴリ
ネットワーク層
IP (IPv4、IPv6) / ICMP / ICMPv6 / NDP / IGMP / IPsec カテゴリ
リンク層
ARP / OSPF / SPB / トンネリング (L2TP) / PPP / MAC （イーサネット、IEEE 802.11、DSL、ISDN） カテゴリ

Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、略称 HTTP）とは、WebブラウザとWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコルである。ハイパーテキスト転送プロトコルとも呼ばれる。

HTTP/1.1 が RFC 7230 から RFC 7235 で規定されている。かつては RFC 2616 が HTTP/1.1 を規定していたため、こちらもよく参照されている。また2010年代に入り、HTTP/1.1 を Google が改良した SPDY が普及したことを受けて、SPDY を基とした HTTP/2 の制定作業が開始され進められている。

概要

名前の通り、 HTML (HyperText Markup Language) や XML (Extensible Markup Language) によって記述されたハイパーテキストの転送を主な目的としているが、それ以外にも、バイナリ形式の画像、音声を含め、様々なデータを扱うことが可能である。その汎用性からセンサーからの定期的なデータの取得などにも用いられる。

トランスポート・プロトコルとして通常TCPを使用する。

HTTPはリクエスト-レスポンス型のプロトコルであり、クライアントがサーバにリクエストメッセージを送信する。 基本的な考え方は非常に単純で、「何を」「どうして」欲しいのかを伝える。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では複数データを効率よく転送するための持続的接続や、プロキシの利用等も想定した仕様になった。

このほかの点を箇条書きで示す。

• ポート番号80をデフォルトとして使用する。
• 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が規定された。
• 行末文字は他の多くのアプリケーション層に属するインターネットプロトコルと同じCRLFである。

歴史

イギリスの物理学者ティム・バーナーズ＝リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。

以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。

最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントであったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。

HTTP/0.9

1991年に最初にドキュメント化されたバージョン。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。

GET /index.html

HTTP/1.0

1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外の物が増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。

HTTP/1.1

1997年1月に RFC 2068 として初版が発表された。その後、2回改訂された。

名前ベースバーチャルホストをサポートした。インターネット人気に伴い多くの企業がWebサイトを持ち始めたが、当時はまだまだ企業が自前のWebサーバを運用するのは人員、効率の問題で難しく、ISPのサーバでホスティングをしていた。また、一社ごとに専用サーバを用意するほどのことでもないため、一台のサーバで複数のWebサイトを運用していた。

しかし、IPアドレスのみで相手を特定するHTTP/1.0はこれに対応できなかった。例えば、ある1台上のサーバに foo.example.com と bar.example.com という二つの仮想Webサーバがあり、クライアントは http://foo.example.com/index.html にアクセスしたいとする。この場合はDNSサーバに foo.example.com のIPアドレスを問い合わせ、次にそのIPアドレスを使って該当サーバにアクセスし、GET index.html を要求することになる。しかし同じサーバ上にある bar.example.comもIPアドレスは同じであり、もし両方の仮想サーバに index.html というファイルが存在すれば、クライアントがどちらにアクセスしようとしているのか、判別できない。

対策としてはそれぞれにIPアドレスを付与する方法もあるが、IPv4の資源を無駄にすることになる。この問題を解決するため、Hostヘッダが追加された。

HTTP/1.0のリクエスト

GET /index.html HTTP/1.0

HTTP/1.1のリクエスト

GET /index.html HTTP/1.1
Host: foo.example.com

HTTP/2

詳細は「HTTP/2」を参照

HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ、Chrome、Opera、Firefox、Amazon Silkが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された。

動作

通信の開始

他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。

クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。

接続

システム間でメッセージをやりとりするにはTCP接続を確立させる必要がある。

HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があったが、これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、HTTP/1.1では持続的接続がサポートされることとなった。ただし、この機能が利用できるのはサーバ側がその要求を許可した場合のみである。

詳細は「HTTPの持続的接続」を参照

パイプライン

クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。

詳細は「HTTPパイプライン」を参照

メソッド

HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドだけで殆どを占める。

HTTPメソッドの一覧

メソッド	HTTP/0.9	HTTP/1.0	HTTP/1.1
GET	○	○	○
POST		○	○
PUT		△	○
HEAD		○	○
DELETE		△	○
OPTIONS			○
TRACE			○
CONNECT			○

GET

指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。

POST

GETとは反対にクライアントがサーバにデータを送信する。Webフォームや電子掲示板への投稿などで使用される。GETの場合と同じく、サーバはクライアントにデータを返すことができる。

PUT

指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。

DELETE

指定したURIのリソースを削除する。

OPTIONS

サーバを調査する。例えば、サーバがサポートしているHTTPバージョンなどを知ることができる。

HEAD

GETと似ているが、サーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることができる。例えばWebページのリンク先が生きているか、データを全て取得することなく検証することができる。

TRACE

サーバまでのネットワーク経路をチェックする。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。

CONNECT

TCPトンネルを接続する。暗号化したメッセージをプロキシサーバを経由して転送する際に用いる。

サーバの連携

バーチャルホスト

上記参照

リダイレクト

別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。

クッキー

詳細は「HTTP cookie」を参照

HTTPメッセージ

クライアントからのHTTPリクエストはメソッド、URI、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。 下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。

クライアントのリクエスト:

GET / HTTP/1.0

メソッドはGET、URIは「/」、HTTPバージョンは1.0である。

GETはリソースを取得するためのメソッドであり、URIの「/」はルートリソースを対象にしたリクエストであることを示している。

サーバのレスポンス:

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><!--
・・・以下省略

先頭のステータス行はHTTPバージョン、ステータスコード、メッセージから構成される。 ステータスコードの「200」は処理の成功を表し、これを補足するメッセージが「OK」である。

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	レスポンスの受け入れ可能転送エンコーディングを示す			○
User-Agent	クライアントのWebブラウザなどの情報を示す		○	○

レスポンスヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Accept-Ranges	オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す			○
Age	オブジェクトの経過時間を秒単位で返す			○
ETag	オブジェクトのエンティティタグ値を示す			○
Location	オブジェクトの場所を示す		○	○
Proxy-Authenticate	プロキシサーバがクライアントに認証を要求するときに用いる			○
Retry-After	リクエストの再試行をいつ行うかをクライアントに通知する		○	○
Server	サーバのベンダー名、バージョン番号を示す		○	○
Set-Cookie2	サーバがクライアントにCookieを送信するときに用いる
Vary	サーバがレスポンス内容を決定する際にリクエストURI以外に用いたヘッダのリストを示す			○
WWW-Authenticate	クライアントに対してリクエストの再発行を要求する。認証情報も含まれる		○	○

一般ヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Cache-Control	メッセージの経由する中間キャッシュの動作を指示する			○
Connection	中間システムが転送すべきでないヘッダのリストを示す		○	○
Date	メッセージの作成日時を示す		○	○
Pragma	メッセージに関する追加情報を示す		○	○
Trailer	メッセージボディの後に追加のヘッダーが表れることを示す			○
Transfer-Encoding	クライアントの転送を目的としたオブジェクトのエンコーディングを示す			○
Upgrade	通信相手に別のプロトコルにアップデートするよう要求する			○
Via	プロキシサーバ等中継地点を示す。			○
Warning	メッセージに関する追加情報を示す。通常はキャッシュの問題を警告するときに使われる			○

エンティティヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Allow	オブジェクトがサポートするHTTPメソッドを示す		○	○
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-Encoding: gzip, deflate

この例ではクライアントはgzip、またはzlibフォーマットに対応している。ただし必ずしもここで指定されたエンコーディングでメッセージボディが返ってくるとは限らない。

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ヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。

Expires: Thu, 28 Aug 2010 16:00:00 GMT

Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。

From

リクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。

From: user@example.com

Host

主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合、レンタルサーバのWebサイトとまともな通信ができないと言ってよい（詳細はHTTP#歴史を参照）。

If-Match

ETagが一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。

「if文」も参照

1. 利用者：AがHTTPの記事を取得。ETagは1234。
2. 利用者：BがHTTPの記事を取得。ETagは1234。
3. 利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。
4. 利用者：AがHTTPの記事を編集。ETagは1256になる。
5. 利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。
6. サーバは利用者：Bの書き込みを拒否。

If-Modified-Since

指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。

If-None-Match

If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。

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桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。

詳細は「HTTPステータスコード」を参照

セキュリティ技術

Basic認証

HTTP/1.1でBasic認証が定義されており最も単純なセキュリティ技術である。しかし仕様書を読むと定義を書いた著者自身が認証技術に疎いことがよくわかる。『HTTPプロトコル セキュア＆スケーラブルなWeb開発』の著者は「基本認証を用いるくらいならなにも使わない方がまし」と著書に書いている。通常サーバはステータスコード401で応答する。

詳細は「Basic認証」を参照

Digest認証

詳細は「Digest認証」を参照

関連項目

• HTTP/2
• HTTPステータスコード
• FTP
• WebDAV
• Webサーバ
• ウェブブラウザ
• アプリケーションサーバ
• REST
• HTTPヘッダ・インジェクション
• Hyper Text Coffee Pot Control Protocol
• バーチャルホスト

参照

外部リンク

• RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
• RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests
• RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching
• RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication
• RFC 2818 - HTTP Over TLS
• RFC 2817 - Upgrading to TLS Within HTTP/1.1
• RFC 2616 - HTTP/1.1（初版，RFC 7230 から RFC 7235 によって obsolete）
  • ハイパーテキスト転送プロトコル -- HTTP/1.1
• RFC 2068 - HTTP/1.1（初版，RFC 2616 によって obsolete）
  • TS X 0085:2004 - ハイパテキスト転送プロトコル HTTP/1.1 標準仕様書(TS)
• RFC 1945 - HTTP/1.0
• The HTTP Protocol As Implemented In W3 - HTTP/0.9

wiki en

[Wiki en表示]

Internet protocol suite
Application layer
BGP DHCP DNS FTP HTTP IMAP LDAP MGCP NNTP NTP POP ONC/RPC RTP RTSP RIP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP more...
Transport layer
TCP UDP DCCP SCTP RSVP more...
Internet layer
IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec more...
Link layer
ARP NDP OSPF Tunnels L2TP PPP MAC Ethernet DSL ISDN FDDI more...

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.

Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext.

The standards development of HTTP was coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs). The first definition of HTTP/1.1, the version of HTTP in common use, occurred in RFC 2068 in 1997, although this was obsoleted by RFC 2616 in 1999.

Technical overview

URL beginning with the HTTP scheme and the WWW domain name label.

HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

A web browser is an example of a user agent (UA). Other types of user agent include the indexing software used by search providers (web crawlers), voice browsers, mobile apps, and other software that accesses, consumes, or displays web content.

HTTP is designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from web cache servers that deliver content on behalf of upstream servers to improve response time. Web browsers cache previously accessed web resources and reuse them when possible to reduce network traffic. HTTP proxy servers at private network boundaries can facilitate communication for clients without a globally routable address, by relaying messages with external servers.

HTTP is an application layer protocol designed within the framework of the Internet Protocol Suite. Its definition presumes an underlying and reliable transport layer protocol, and Transmission Control Protocol (TCP) is commonly used. However HTTP can use unreliable protocols such as the User Datagram Protocol (UDP), for example in Simple Service Discovery Protocol (SSDP).

HTTP resources are identified and located on the network by uniform resource locators (URLs), using the uniform resource identifier (URI) schemes http and https. URIs and hyperlinks in Hypertext Markup Language (HTML) documents form inter-linked hypertext documents.

HTTP/1.1 is a revision of the original HTTP (HTTP/1.0). In HTTP/1.0 a separate connection to the same server is made for every resource request. HTTP/1.1 can reuse a connection multiple times to download images, scripts, stylesheets, etc after the page has been delivered. HTTP/1.1 communications therefore experience less latency as the establishment of TCP connections presents considerable overhead.

History

Tim Berners-Lee

The term hypertext was coined by Ted Nelson in 1965 in the Xanadu Project, which was in turn inspired by Vannevar Bush's vision (1930s) of the microfilm-based information retrieval and management "memex" system described in his essay As We May Think (1945). Tim Berners-Lee and his team at CERN are credited with inventing the original HTTP along with HTML and the associated technology for a web server and a text-based web browser. Berners-Lee first proposed the "WorldWideWeb" project in 1989 — now known as the World Wide Web. The first version of the protocol had only one method, namely GET, which would request a page from a server. The response from the server was always an HTML page.

The first documented version of HTTP was HTTP V0.9 (1991). Dave Raggett led the HTTP Working Group (HTTP WG) in 1995 and wanted to expand the protocol with extended operations, extended negotiation, richer meta-information, tied with a security protocol which became more efficient by adding additional methods and header fields. RFC 1945 officially introduced and recognized HTTP V1.0 in 1996.

The HTTP WG planned to publish new standards in December 1995 and the support for pre-standard HTTP/1.1 based on the then developing RFC 2068 (called HTTP-NG) was rapidly adopted by the major browser developers in early 1996. By March 1996, pre-standard HTTP/1.1 was supported in Arena, Netscape 2.0, Netscape Navigator Gold 2.01, Mosaic 2.7, Lynx 2.5, and in Internet Explorer 2.0. End-user adoption of the new browsers was rapid. In March 1996, one web hosting company reported that over 40% of browsers in use on the Internet were HTTP 1.1 compliant. That same web hosting company reported that by June 1996, 65% of all browsers accessing their servers were HTTP/1.1 compliant. The HTTP/1.1 standard as defined in RFC 2068 was officially released in January 1997. Improvements and updates to the HTTP/1.1 standard were released under RFC 2616 in June 1999.

In 2007, the HTTPbis Working Group was formed, in part, to revise and clarify the HTTP/1.1 specification. In June 2014, the WG released an updated six-part specification obsoleting RFC 2616:

• RFC 7230, HTTP/1.1: Message Syntax and Routing
• RFC 7231, HTTP/1.1: Semantics and Content
• RFC 7232, HTTP/1.1: Conditional Requests
• RFC 7233, HTTP/1.1: Range Requests
• RFC 7234, HTTP/1.1: Caching
• RFC 7235, HTTP/1.1: Authentication

HTTP/2 was published as RFC 7540 in May 2015.

HTTP session

An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server (typically port 80, occasionally port 8080; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for a client's request message. Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own. The body of this message is typically the requested resource, although an error message or other information may also be returned.

HTTP Authentication

HTTP provides multiple authentication schemes such as Basic access authentication and Digest access authentication which operate via a challenge-response mechanism whereby the server identifies and issues a challenge before serving the requested content.

HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information.

Authentication Realms

The HTTP Authentication spec also provides an arbitrary, implementation specific construct for further dividing resources common to a given root URI. The realm value string, if present, is combined with the canonical root URI to form the protection space component of the challenge. This in effect allows the server to define separate authentication scopes under one root URI

Request methods

An HTTP 1.1 request made using telnet. The request message, response header section, and response body are highlighted.

HTTP defines methods (sometimes referred to as verbs) to indicate the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server. The HTTP/1.0 specification defined the GET, POST and HEAD methods and the HTTP/1.1 specification added 5 new methods: OPTIONS, PUT, DELETE, TRACE and CONNECT. By being specified in these documents their semantics are well known and can be depended upon. Any client can use any method and the server can be configured to support any combination of methods. If a method is unknown to an intermediate it will be treated as an unsafe and non-idempotent method. There is no limit to the number of methods that can be defined and this allows for future methods to be specified without breaking existing infrastructure. For example, WebDAV defined 7 new methods and RFC 5789 specified the PATCH method.

GET

The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.) The W3C has published guidance principles on this distinction, saying, "Web application design should be informed by the above principles, but also by the relevant limitations." See safe methods below.

HEAD

The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

POST

The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.

PUT

The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.

DELETE

The DELETE method deletes the specified resource.

TRACE

The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.

OPTIONS

The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.

CONNECT

The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy. See HTTP CONNECT tunneling.

PATCH

The PATCH method applies partial modifications to a resource.

All general-purpose HTTP servers are required to implement at least the GET and HEAD methods, and, whenever possible, also the OPTIONS method.

Safe methods

Some of the methods (for example, HEAD, GET, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe. However, this is not mandated by the standard, and it is explicitly acknowledged that it cannot be guaranteed.

By contrast, methods such as POST, PUT, DELETE and PATCH are intended for actions that may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers; some that do not conform tend to make requests without regard to context or consequences.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause non-trivial changes on the server. This is discouraged, because it can cause problems for web caching, search engines and other automated agents, which can make unintended changes on the server.

Idempotent methods and web applications

Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time). Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.

In contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.

Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other non-idempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it isn't.

Security

Implementing methods such as TRACE, TRACK and DEBUG are considered potentially insecure by some security professionals because attackers can use them to gather information or bypass security controls during attacks. Security software tools such as Tenable Nessus and Microsoft UrlScan Security Tool report on the presence of these methods as being security issues. TRACK and DEBUG are not valid HTTP 1.1 verbs.

Status codes

See also: List of HTTP status codes

In HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as "404") and a textual reason phrase (such as "Not Found"). The way the user agent handles the response primarily depends on the code and secondarily on the other response header fields. Custom status codes can be used since, if the user agent encounters a code it does not recognize, it can use the first digit of the code to determine the general class of the response.

The standard reason phrases are only recommendations and can be replaced with "local equivalents" at the web developer's discretion. If the status code indicated a problem, the user agent might display the reason phrase to the user to provide further information about the nature of the problem. The standard also allows the user agent to attempt to interpret the reason phrase, though this might be unwise since the standard explicitly specifies that status codes are machine-readable and reason phrases are human-readable. HTTP status code is primarily divided into five groups for better explanation of request and responses between client and server as named: Informational 1XX, Successful 2XX, Redirection 3XX, Client Error 4XX and Server Error 5XX.

Persistent connections

Main article: HTTP persistent connection

In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request. Such persistent connections reduce request latency perceptibly, because the client does not need to re-negotiate the TCP 3-Way-Handshake connection after the first request has been sent. Another positive side effect is that in general the connection becomes faster with time due to TCP's slow-start-mechanism.

Version 1.1 of the protocol also made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before waiting for each response. Another improvement to the protocol was byte serving, where a server transmits just the portion of a resource explicitly requested by a client.

HTTP session state

HTTP is a stateless protocol. A stateless protocol does not require the HTTP server to retain information or status about each user for the duration of multiple requests. However, some web applications implement states or server side sessions using for instance HTTP cookies or hidden variables within web forms.

Encrypted connections

The most popular way of establishing an encrypted HTTP connection is HTTP Secure. Two other methods for establishing an encrypted HTTP connection also exist: Secure Hypertext Transfer Protocol, and using the HTTP/1.1 Upgrade header to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.

Request message

The request message consists of the following:

• A request line, for example GET /images/logo.png HTTP/1.1, which requests a resource called /images/logo.png from the server.
• Request header fields, such as Accept-Language: en.
• An empty line.
• An optional message body.

The request line and other header fields must each end with <CR><LF> (that is, a carriage return character followed by a line feed character). The empty line must consist of only <CR><LF> and no other whitespace. In the HTTP/1.1 protocol, all header fields except Host are optional.

A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification in RFC 1945.

Response message

The response message consists of the following:

• A Status-Line, which include the status code and reason message. (e.g., HTTP/1.1 200 OK, which indicates that the client's request succeeded)
• Response header fields, such as Content-Type: text/html.
• An empty line
• An optional message body

The Status-Line and other header fields must all end with <CR><LF> (a carriage return followed by a line feed). The empty line must consist of only <CR><LF> and no other whitespace.

Example session

Below is a sample conversation between an HTTP client and an HTTP server running on www.example.com, port 80.

Client request

GET /index.html HTTP/1.1
Host: www.example.com

A client request (consisting in this case of the request line and only one header field) is followed by a blank line, so that the request ends with a double newline, each in the form of a carriage return followed by a line feed. The "Host" field distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.

Server response

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
ETag: "3f80f-1b6-3e1cb03b"
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

The ETag (entity tag) header field is used to determine if a cached version of the requested resource is identical to the current version of the resource on the server. Content-Type specifies the Internet media type of the data conveyed by the HTTP message, while Content-Length indicates its length in bytes. The HTTP/1.1 webserver publishes its ability to respond to requests for certain byte ranges of the document by setting the field Accept-Ranges: bytes. This is useful, if the client needs to have only certain portions of a resource sent by the server, which is called byte serving. When Connection: close is sent, it means that the web server will close the TCP connection immediately after the transfer of this response.

Most of the header lines are optional. When Content-Length is missing the length is determined in other ways. Chunked transfer encoding uses a chunk size of 0 to mark the end of the content. Identity encoding without Content-Length reads content until the socket is closed.

A Content-Encoding like gzip can be used to compress the transmitted data.

Similar protocols

The Gopher protocol was a content delivery protocol that was displaced by HTTP in the early 1990s. The protocol SPDY is also similar to HTTP, modifying the request-response interaction between client and server.

See also

HTTP
Persistence Compression HTTPS
Request methods
OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT PATCH
Header fields
Cookie ETag Location HTTP referer DNT X-Forwarded-For
Status codes
301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found 451 Unavailable For Legal Reasons

• Basic access authentication
• Constrained Application Protocol – A semantically similar protocol to HTTP but used UDP or UDP-like messages targeted for devices with limited processing capability. Re-uses HTTP and other internet concepts like Internet media type and web linking (RFC 5988)
• Content negotiation
• Curl-loader – HTTP/S loading and testing open-source software
• Digest access authentication
• Fiddler (software)
• HTTP compression
• HTTP/2 – developed by the IETF's Hypertext Transfer Protocol Bis (httpbis) working group.
• HTTP-MPLEX – A backwards compatible enhancement to HTTP to improve page and web object retrieval time in congested networks proposed by Robert Mattson
• List of file transfer protocols
• List of HTTP header fields
• List of HTTP status codes
• Representational state transfer (REST)
• Variant object
• Waka (protocol) – An HTTP replacement proposed by Roy Fielding
• Web cache
• WebSocket
• Wireshark

Notes

References

• HTTP 0.9 – As Implemented in 1991

External links

• "Change History for HTTP". W3.org. Retrieved 2010-08-01.  A detailed technical history of HTTP.
• "Design Issues for HTTP". W3.org. Retrieved 2010-08-01.  Design Issues by Berners-Lee when he was designing the protocol.
• "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01.  list of other classic documents recounting the early protocol history

English Journal

• COGITA network has constructed a glossary of diagnostic reasoning terms.

• Barais M1, Hauswaldt J2, Dinant GJ3, van de Wiel M4, Stolper CF3,5, Van Royen P6.
• The European journal of general practice.Eur J Gen Pract.2017 Dec;23(1):53-56. doi: 10.1080/13814788.2016.1242569.
• PMID 28271949

• Results of a randomized controlled trial analyzing telemedically supported case management in the first year after living donor kidney transplantation - a budget impact analysis from the healthcare perspective.

• Kaier K1, Hils S2, Fetzer S3, Hehn P4, Schmid A2, Hauschke D4, Bogatyreva L4, Jänigen B2, Pisarski P2.
• Health economics review.Health Econ Rev.2017 Dec;7(1):1. doi: 10.1186/s13561-016-0141-3. Epub 2017 Jan 13.
• PMID 28092012

• Efficacy and tolerability of lithium in treating acute mania in youth with bipolar disorder: protocol for a systematic review.

• Duffy A1,2, Patten S3, Goodday S4, Weir A5,6, Heffer N7, Cipriani A8,9.
• International journal of bipolar disorders.Int J Bipolar Disord.2017 Dec;5(1):22. doi: 10.1186/s40345-017-0092-6. Epub 2017 Jun 13.
• PMID 28447333

Japanese Journal

• 「歴史研究のため財務記録史料マークアップ手法」和訳

• 小風 尚樹
• 2015-06-01
• … Charles Muller、永崎研宣）の一環として、担当教員諸氏による指導に基づき、 Kathryn Tomasek and Syd Bauman, 'Encoding Financial Records for Historical Research', Journal of the Text Encoding Initiative [Online], Issue 6 | December 2013, Online since 26 September 2013, URL : http://jtei.revues.org/895 を翻訳したもの。 … ODD文書の暫定的なバージョンについては、「財務記録史料の符号化」(http://www.customization.encodinghfrs.org/) で利用可能である。 …
• NAID 120005606204

• A Structure behind Primitive Chaos

• Ogasawara Yoshihito
• Journal of the Physical Society of Japan 84(6), 2015-05-28
• NAID 160000000735

• Effect of Parallel Magnetic Field on Superconductivity of Ultrathin Metal Films Grown on a Cleaved GaAs Surface

• Sekihara Takayuki,Miyake Takahiro,Masutomi Ryuichi,Okamoto Tohru
• Journal of the Physical Society of Japan 84(6), 2015-05-21
• NAID 160000000750

Related Links

• HTTP(エイチ ティー ティー ピー)とは - コトバンク

ASCII.jpデジタル用語辞典 - HTTPの用語解説 - HTML文書や画像などのデータをWebサーバーとWebブラウザー間でやり取りするために使われるプロトコル。HTTPでは、データを受信する側（クライアント）が要求をサーバーに伝え、それに対して ...

• 株式会社WPS | トップページ

株式会社WPSトップページ。みなさまの「美味しい」の良きパートナーを目指して。 ... 2017/03/27 WEBサイトをOPENしました。 2017/03/03 当社BRAND「厚切り牛かつ専門店『神戸牛かつ亭』」が三宮にOPEN。

Related Pictures

---

★リンクテーブル★

関連記事

「HT」

「HT」

　　[★]

• 高血圧症 高血圧 hypertension
• 心移植 heart transplantation