HTTPリクエストヘッダ

通信プロトコルHTTP

HTTPリクエストヘッダとは?

 状態:-  閲覧数:913  投稿日:2016-03-08  更新日:2016-05-05
受け取り希望(Accept、Accept-Language、Accept-Encoding、Accept-Charset)
・どんなデータを受け取りたいか、画像の種類や、言語、エンコード、文字コードなどの希望を伝える
・英語バージョンと日本語バージョンなど複数の内容を提供している場合、サーバーはこの情報を元に適切な情報を返したりすることが可能

A → B

 閲覧数:174 投稿日:2016-02-29 更新日:2016-04-05 

MIMEタイプ(Accept)


ブラウザが受信可能なデータ形式(MIMEタイプ)をサーバへ通知
・クライアントの受け入れ可能なコンテンツタイプをサーバへ示す
・サーバのレスポンスに含まれるメッセージボディで受け入れることが出来るコンテンツタイプと各コンテンツタイプの相対的な優先度を指定
・指定できるコンテンツタイプはIANAによって定義されている
・アスタリスク(*)は「すべて」の意味

ブラウザが GIF や JPEG、その他どんな形式のデータでも受信可能であることを示す例
・数値の指定がなければ1.0となる
Accept: image/gif, image/jpeg, */*

相対的な優先度指定例
・Acceptヘッダは行をわけて複数のコンテンツタイプを指定可能
・下記例は何れも受け入れ可能であることを示す
・0.5や0.8といった数字は品質係数
・0〜1の範囲の数値
Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c


文字コード(Accept-Charset)


ブラウザが受信可能な文字セットをサーバへ通知
・クライアントの受け入れ可能な文字セットをサーバへ示す
・レスポンスで返されるメッセージボディの文字コードを指定
・Acceptと同じく複数指定可能
・品質係数も設定可能
・定義済み文字セットはIANAが管理している

ブラウザが iso-8859-5 と Shift_JIS のみを受信可能であることを示す例
Accept-Charset: iso-8859-5, Shift_JIS

相対的な優先度指定例
・下記例ではクライアントはUnicode文字セットを優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている
・但しサーバからのレスポンスのHTTPヘッダそのものの文字コードは、常にISO-8859-1となる
Accept-Charset: unicode, *; q=0.8


ブラウザエンコード方式(Accept-Encoding)


ブラウザが受信可能なエンコード方式をサーバへ伝達
・クライアントの受け入れ可能文字エンコーディングを示す
・クライアントが受信できるメッセージボディのエンコーディングを指定

クライアントがgzip、またはzlibフォーマットに対応している例
・ブラウザが gzip 形式をサポートしていることをサーバへ伝達
・サーバはメッセージボディを自動的に gzip 圧縮してブラウザに送り、ブラウザ側がこれを自動的に解凍して画面に表示
・通信負荷を低減することが可能
・但しここで指定されたエンコーディングで、メッセージボディが必ずしも返ってくるとは限らない
Accept-Encoding: gzip, deflate
Accept-Encodingは、文字エンコーディングを含む? それとも、文字エンコーディングだけ?



ブラウザ言語(Accept-Language)


ブラウザが受信可能な言語をサーバへ伝達
・クライアントの受け入れ可能言語を示す
・レスポンスの言語(人間の言語)に対する優先度を指定
・言語コードはISO-639の2文字の省略コードを用いる
・書き方は他のAccept-群と同一

ブラウザが日本語のみ受信可能であることを示す例
Accept-Language: ja

まずイギリス英語を要求し、利用できない場合はその他の英語を要求する例
Accept-Language: en-gb, en; q=0.8


サポートするHTTPメソッド(Allow)


オブジェクトがサポートするHTTPメソッドを示す
・リクエストURL で示すリソースに対して使用可能なメソッドの一覧
・下記例では、このリソースに対して GET、HEAD、PUT メソッドを使用可能であることを示す
Allow: GET, HEAD, PUT


認証(Authentication-info)


ユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダ


認証(Authorization)


サーバへ対するクライアント自身の認証を行うことが出来る
・クライアントの認証情報を示す
・認証が必要なリソースに対して認証情報を伝達
・BASIC認証の場合は、Basic の文字と、ユーザ名とパスワードをコロン(:)で連結したものを BASE64 形式にエンコードしたものを転送
Authorization: Basic c2FrdXJhOnBhc3N3b3Jk=


C →

 閲覧数:191 投稿日:2016-03-02 更新日:2016-05-04 

キャッシュ(Cache-Control)


メッセージを経由する中間キャッシュの動作を指示
・下記例では、プロキシサーバやクライアントがこのリソースをキャッシュしてはならないことを示す
・HTTP/1.0 では Pragma: no-cache が使用されます
Cache-Control: no-cache


持続(Connection)


HTTP/1.1 でサポートされた持続機能をブラウザがサポートしている場合、その旨を相手に伝えます
・1回の接続で複数のリクエスト/レスポンスを発行することが可能になります
Connection: Keep-Alive
持続接続を完了する場合、サーバは close を返却します
Connection: close
その他にも、サーバ・プロキシ間、プロキシ・クライアント間のような直接接続にのみ有効なヘッダの一覧を示すために用いられます
・プロキシサーバはこのヘッダで指定されたヘッダ情報を削除して、転送しなくてはなりません
Connection: Upgrade


コンテンツのエンコード方式(Content-Encoding)


コンテンツのエンコード方式を示します
・下記は、コンテンツが gzip 形式で圧縮されていることを示します
Content-Encoding: gzip


コンテンツの言語(Content-Language)


コンテンツの言語を en(英語)、ja(日本語)などで示す
・リソースを英語などの自然言語で示すのに使われる
・言語の指定はAccept-Languageヘッダと同じ
Content-Language: ja


コンテンツの長さ(Content-Length)


コンテンツ(=メッセージボディ)の長さをバイト単位で示します
・ヘッダとメッセージボディの間の改行のバイト数は除きます
Content-Length: 4891


URL(Content-Location)


オブジェクトの場所
・コンテンツが別の URL でもアクセス可能なとき、そのエンティティの URL を絶対URL または相対URL で示す
Location: http://xxx.yyy.zzz/index.htm


メッセージダイジェスト(Content-MD5)


オブジェクトのメッセージダイジェストを運ぶ
・コンテンツが通信途中で改変されていないかチェックするため、コンテンツに関するチェックデータ(128ビットのMD5ダイジェストをBASE64エンコードしたもの)を示す
・メッセージボディが変更されず宛先に届くことを保証する
・MD5アルゴリズムを実行する
・但し、悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない
・どちらかといえば偶発的な変更の保証をしている
Content-MD5: GitH4qFa4GasgWxJs8ha5Q==


コンテンツの範囲(Content-Range)


メッセージボディで運ばれるオブジェクトの範囲
・相手に送信するコンテンツの範囲を示す
・ダウンロードの再開に用いられる
・下記例では、コンテンツ全体は 12345バイトあり、その中の 0バイト目から 999バイト目の部分を送信していることを示す
Content-Range: bytes 0-999/12345


コンテンツの種別(Content-Type)


メッセージボディに含まれるオブジェクトタイプ
・コンテンツの種別を MIMEタイプで示す

コンテンツの内容がテキスト(HTML)形式であることを示す例
Content-Type: text/html

コンテンツの内容がテキスト(HTML)形式であることに加え、文字コード(Shift_JIS、euc-jp、ISO-2022-JP、UTF-8 など)を示す例
Content-Type: text/html; charset=Shift_JIS

リソースがテキストファイル、文字セットはISO-8859-4を使用していることを示す例
Content-Type: text/plain; Charset=ISO-8859-4


クッキー(Cookie)


クライアントの状態管理情報をサーバに返す
・ブラウザに保存されているクッキーデータは毎回サーバーに送信されている
・クライアントがHTTP状態管理を望む場合、サーバから受け取ったクッキーを以後のリクエストヘッダに付加する
・ログイン状態を続けられるのは、ログイン時にサーバーから送られたクッキーをブラウザが保存しておいて、リクエストの際に送っているから

$VersionはHTTPのバージョン、NAMEはクッキーの名前
・$から始まるクッキー名は使用が禁止されている
Cookie: $Version="1"; NAME="VALUE";
       $Path="/shopping"; $domain="www.shop.com"+
       $Port="80"


Set-Cookie2ヘッダ受入可(Cookie2)


HTTP/1.1のSet-Cookie2ヘッダの受け入れ可能をサーバに知らせる
Cookie2
Cookie2 は IETF によって RFC 2109, RFC 2965 として標準化

D → F

 閲覧数:158 投稿日:2016-03-11 更新日:2016-03-27 

メッセージの作成日時(Date)


サーバがメッセージを生成した日時を示す
・リソースの更新日時を示すLast-Modifiedヘッダとは別
・曜日(Sun,)は省略可能
・日付は 1 でも 01 でも構わない
・年は 2桁でも 4桁でも構わないが 4桁が推奨されている
・秒(:23)は省略可能

HTTP/1.1では次のような形式を用いるようRFC1123で定義されている
Date: Sun, 06, Nov 1994 08:49:37 GMT

時間帯は GMT(グリニッジ標準時)を用いることが多い
Date: Sun, 04 Jan 2004 16:06:23 GMT


サーバへ期待する動作(Expect)


クライアントがサーバへ期待する動作を示す
・サーバへ対して期待する特定動作を知らせる

クライアントがサーバへ対して100 Continueステータスを返すことを期待する場合に使われる
Expect: 100-continue

・サーバが期待に応じられない場合は417 Expectation Failedを返す
・クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない


有効期限の日時(Expires)


オブジェクトの有効期限日時を示す
・このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことができる
・サーバがオブジェクトのキャッシュを望まない場合にはExpiresヘッダへ過去の日時を設定することが多い
・仕様では1年以上先の日時を設定できない
・有効期限を過ぎたエンティティはキャッシュから削除される
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: Thu, 28 Aug 2010 16:00:00 GMT

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


リクエスト発行者個人の情報(From)


リクエスト発行者個人の情報を示す
・リクエストを発行したユーザを特定することが出来る
・一般的にこのリクエストを行った人の電子メールアドレスを指定する
・検索エンジンがロボットで探索する場合に、探索に関する問い合わせ先のメールアドレスを通知する際などに利用される
・1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない
From: aaa@xxx.yyy.zzz
From: user@example.com


H → K

 閲覧数:166 投稿日:2016-03-11 更新日:2016-03-27 

サーバ名(Host)


ブラウザからサーバへ対して、サーバ名を送信
・HTTP/1.1 で唯一の必須ヘッダ
・要求しているオブジェクトがあるホストを示す
・主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された
・サーバが名前ベースの仮想ホストをサポートしている場合、この名前を手がかりにどのサーバとして振舞うか決定される
・例えば、http://aaa.sample.co.jp/ と http://bbb.sample.co.jp/ は実は同じサーバ(IPアドレス:12.345.67.809)だが、Host ヘッダでホスト名を指定することにより、仮想的に 2つのサーバとして振舞うことが可能になる
Host: aaa.sample.co.jp


ETagが一致した場合のみ、メソッドを実行するようにサーバへ要求(If-Match)


if文を用い条件が真の場合のみリクエストを処理するようサーバへ要求する
・指定した ETag にマッチする場合にのみ、メソッドを実行することをサーバへ依頼
If-Match: "1dba6-131b-3fd31e4a"

例えばウィキペディアを編集する際、「記事のソースを取得し書き換える間に別のユーザが既に編集していないか」を判断するときなどに用いられる
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)


「指定日時以降にオブジェクトが変更されている場合のみ」リクエストを処理するようサーバへ要求する
・通信量の削減に効果がある

仕組み
・ブラウザは、一度表示したデータを「ローカルキャッシュ」として保存
・同じデータを何度も通信して取得しなくても済むようにしている
・その際、ローカルキャッシュのデータが変更されていないかチェックするため、ファイルの変更日付や管理情報をリクエストに含めておく
・「更新有無判断」で使用

クライアント側がすでにキャッシュを持っている場合、キャッシュの日付をサーバに通知し、「この日付よりも新しいものがあれば転送してくれ」と要求
・もし、更新されていなければサーバは 304(not modified)ステータスを返し、ブラウザはキャッシュしていたデータを表示
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT


条件が真でない場合のみリクエスト(If-None-Match)


If-Matchの逆で条件が真でない場合のみリクエストを処理する要求
・指定した ETag にマッチしない場合にのみ、メソッドを実行することをサーバへ依頼
If-None-Match: "1dba6-131b-3fd31e4a"


真の場合のみオブジェクトの範囲を返す(If-Range)


条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する
・クライアントが、エンティティの一部をすでに保持している場合に、「もし、この ETag で指定したエンティティの一部が最新のものであるならば、残りのすべてを、さもなくば全体を送信してくれ」の意味で要求
・クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる
・Range ヘッダと組み合わせて使用
Range: bytes=0-1023
If-Range: "1dba6-131b-3fd31e4a"


If-Modified-Sinceの逆(If-Unmodified-Since)


If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみ実行を要求する
・エンティティが、指定した日付よりもあとに更新されていなければ、要求を処理
・更新されている場合、サーバは 412(Precondition Failed)ステータスを返す
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT


L → S 

 閲覧数:162 投稿日:2016-03-11 更新日:2016-03-27 

中間システム経由最大数( Max-Forwards)


リクエストの中間システム経由数が最大いくつまでかを指定する
・プロキシサーバ等を経由する際の最大ホップ数を指定する
・二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる
・プロキシサーバはこの値をひとつ減算して、次のプロキシサーバへ転送
・この値が 0 になると、プロキシサーバは最後の受信者として応答を返す
Max-Forwards: 16


メッセージに関する追加情報(Pragma)


メッセージに関する追加情報を示す
・様々な目的で使用される
・下記はキャッシュを禁止する旨をプロキシサーバやクライアントに通知
Pragma: no-cache


プロキシサーバへ対する自身の認証( Proxy-Authorization)


クライアントがプロキシサーバへ対して自身の認証を行う
・プロキシサーバとクライアント間の認証情報を渡す
Proxy-Authorization: Basic dGFuYWthOmhpbWl0c3U=


リソースの一部( Range)


オブジェクト全体でなくリソースの一部を要求する
・クライアントからサーバに対して、エンティティの一部のみを要求
・下記例では、ページの最初の 1000バイト(0バイト目から 999バイト目)のみを要求
Range: bytes=0-999


リファラ( Referer)


どのページから発生したリクエストなのか
・リクエストの出所を示す
・一般的にはユーザの辿ったWebページのURLが用いられる
・このリクエスト元となったページ URL(通常はリンク元のURL)を通知
・ページAにあるリンクをクリックしてページBに行った場合、ページBへのHTTPリクエストにリファラーとしてページAが入る
・ページCを表示する際にページ内で使われている画像をリクエストする際に、画像のHTTPリクエストにリファラーとしてページCが入る
Referer: http://xxx.yyy.zzz/index.html

「リファラー」の綴りは本当は「referrer」が正しい
・当初間違って使われた「referer」がそのまま使われている

T → Z

 閲覧数:173 投稿日:2016-03-12 更新日:2016-03-24 

受け入れ可能転送エンコーディング(TE)


レスポンスの受け入れ可能転送エンコーディングを示す
・ブラウザが処理可能な拡張転送コーディング方式(chunked など)や、チャンク転送の際の trailer フィールドを解釈可能かどうかをサーバへ伝達
TE: trailers


付加されたヘッダの一覧(Trailer)


メッセージボディの後に追加のヘッダーが表れることを示す
・ヘッダ情報をコンテンツの先頭ではなく、チャンク形式で分割送信されたコンテンツの後ろに付加する場合、そこに付加されたヘッダの一覧を示す
・これは、CGI がデータ送信した後に Content-Length ヘッダを付加したい場合などに役立つ
Trailer: Content-Length


転送エンコード形式(Transfer-Encoding)


転送に使用されるエンコード形式
・クライアントの転送を目的としたオブジェクトのエンコーディングを示す
Transfer-Encoding: chunked


別プロトコル推奨(Upgrade)


別のプロトコルを用いることを推奨する旨を相手へ伝達
・通信相手に別のプロトコルへアップデートするよう要求する
・クライアント・プロキシ間のような直接接続にのみ有効
Upgrade: HTTP/2.0, SHTTP/1.3


ユーザーエージェント名(User-Agent)


クライアントのWebブラウザなどの情報
・ブラウザ(=ユーザエージェント)の情報をサーバへ伝達
・フォーマット規定は特になし
・ブラウザ種別やバージョン、プラットフォームなどの情報が含まれる
・ブラウザではなく検索エンジンのクローラがアクセスしている場合、「Googlebot」などの名前が入る
・下記は、Mozilla/4.0(=Netscape Navigator 4.0)と互換性のある Microsoft の IE 6.0 で、OS は Windows NT 5.1(=Windows XP)であることを示している
User-Agent: Mozilla/4.0 (Compatible; MSIE 6.0; Windows NT 5.1;)


中継地点(Via)


プロキシサーバ等中継地点を示す
・メッセージの転送経路
・下記例では、メッセージが aaa → bbb → ccc というプロキシを経路して転送されたことを示す
・1.1 はプロトコルバージョン
Via: 1.1 aaa, 1.1 bbb, 1.1 ccc


メッセージに関する追加情報(Warning)


ステータス行に付加されるワーニングコードとメッセージを伝達
・通常はキャッシュの問題を警告するときに使用される
Warning: 110 xxxsv "Response is stale"


サーバの実装による様々なヘッダ(extension-header )


上記の他にも、サーバの実装により様々なヘッダが実装されています

Twitter検索結果。「HTTPリクエストヘッダ」に関する最新ツイート


HTTPヘッダ確認ツール / HTTPリクエストのサンプル / HTTPメソッド

HTTPレスポンスヘッダ



週間人気ページランキング / 9-19 → 9-25
順位 ページタイトル抜粋 アクセス数
1 Nginx設定。エラーログレベル | Nginx(Webサーバ) 16
2 PHP実行ユーザ設定 / CentOS6 / Apache | PHP(プログラミング言語) 15
3 PHPのmb_send_mail関数でメール送信できない | メール処理システム 11
4 9回目-13.MySQL5.7.21設定 | CentOS 7 2週間無料のお試し期間 9回目(さくらVPS) 10
5 tar: これは tar アーカイブではないようです 8
5 ImageMagick と imagick の違い | ImageMagick(ソフトウェアスイート) 8
5 さくらVPS0 8
6 manページ日本語表示 | CentOS 7 (CentOS) 7
6 Python 3.5 アンインストール / yum remove | Python(プログラミング言語) 7
7 ABRT により 問題が検出されました | CentOS 7 (CentOS) 6
7 Reached target Shutdown メッセージが表示されたあと、シャットダウンまたは再起動プロセスがハングアップする | CentOS 7 (CentOS) 6
7 PHPファイルでchmodエラー | PHP(プログラミング言語) 6
7 echo と cat の違い 6
8 FFmpeg 2.8.15 を yum インストール | ソフトウェアスイート 5
8 「設定ファイルに、暗号化 (blowfish_secret) 用の非公開パスフレーズの設定を必要とするようになりました。」対応 5
8 「CentOS6」から「CentOS7」への移行 | CentOS 7 (CentOS) 5
8 「さくらVPS」で、「CentOS6」を「CentOS7」へ変更するためには? | CentOS 7 2週間無料のお試し期間 Link(さくらVPS) 5
9 6回目-10.Nginxでバーチャルホスト設定確認 | CentOS 7 2週間無料のお試し期間 6回目(さくらVPS) 4
9 cronで定期実行しているphpファイルを、コマンドライン経由で即時実行する | cron(Linuxコマンド) 4
9 MySQL 5.5 から 5.6 へのアップグレード | MySQL(データベース) 4
2021/9/26 1:01 更新