あなたがブラウザで見ているものは、ほとんどすべて HTTP プロトコルによってあなたのコンピューターに送信されています。例えば、この記事のページを開いたとき、ブラウザはたくさんの HTTP リクエスト （Request）を送信し、たくさんのレスポンス （Response）を受信しました。

HTTP ヘッダ ( Header) は、これらのリクエストとレスポンスの重要な部分です。 HTTP ヘッダはリクエストとレスポンスの重要な部分で、クライアントのブラウザ、リクエストされたページ、サーバなどに関する情報を伝達します。

このチュートリアルでは、ヘッダから必要な情報を取得する方法について説明します。 Request Headers.このチュートリアルでは、リクエストヘッダから興味のある情報を取得する方法( Request Headers)から必要な情報を取得し、必要なレスポンスヘッダに特定の値を設定する方法について説明します( Response Headers).

のコンテンツに関する情報を取得する最も簡単な方法は、公開されたリクエストを実行することです。 Request Headers の内容に関する情報を得る最も簡単な方法は、公開アプリケーションでリクエストを実行することです。

デベロッパーツール( F12).
に切り替えます。 Networks タブに切り替えます。
送信されたリクエストを一覧から選択する。
に切り替えます。 Headers タブをクリックし Request Headers のセクションをご覧ください。

AppMasterを使ってRequest-Response Headersとやり取りする方法

バックエンドデザイナーで AppMaster バックエンドデザイナーでは、その名前がビジネスプロセスブロックで指定されていれば、リクエストヘッダ情報を取得することができます。 Get Request Headers ビジネスプロセスブロックにその名前が指定されていれば、バックエンドデザイナーでリクエストヘッダの情報を取得できます。

Name[ string]- ヘッダーの名前
Value[ string]- ヘッダーの値。

カスタム Header をレスポンスに追加するには Set Response Header ブロックが使用されます。

Name [文字列] - ヘッダーの名前。
Value[文字列] - ヘッダーの値。

多くの Request Headers が存在しますが、そのうちのいくつかを以下に説明します（情報は https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html から引用しています）。

From- インターネットメール形式では、これは要求しているユーザーの名前を与える。このフィールドは、ログ記録の目的およびアクセス保護の安全でない形で使用されるかもしれない。このフィールドの解釈は、リクエストが与えられた人の代理として実行され、その人が実行された方法に対する責任を受け入れるというものである。このフィールドのインターネットメールアドレスは、リクエストを発行したインターネットホストに対応する必要はない。(例えば、リクエストがゲートウェイを通過する場合、オリジナルの発行者のアドレスが使用されるべきである)。メールアドレスは、それが実際にインターネット上のメールアドレスであるか、他のメールシステム上のアドレスのインターネットメール表現であるかに関わらず、可能であれば有効なメールアドレスであるべきである。
Accept- このフィールドは、このリクエストに対する応答で受け入れられる表現スキーム(Content-Type metainformation values)のセミコロンで区切られたリストを含む。与えられたセットはもちろん、同じユーザーからのリクエストごとに異なるかもしれません。

例

例: Accept: text/plain, text/html

Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c
Accept-Encoding- Acceptと似て いますが、レスポンスで受け入れ可能な Content-Encodingの 種類を列挙しています。

例

例: Accept-Encoding: x-compress; x-zip
Referer- このオプションのヘッダーフィールドは、サーバーの利益のために、リクエストのURIを取得したドキュメント(またはドキュメント内のエレメント)のアドレス (URI )をクライアントが指定することを可能にする。これにより、サーバーはドキュメントへのバックリンクのリストを生成し、興味を引いたり、ログに記録したりすることができます。また，保守のために不正なリンクを追跡することができる。部分的なURIが与えられた場合，それはリクエストのオブジェクトのURIに関連してパースされるべきである。

例

Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Authorization- この行が存在する場合、それは認証情報を含んでいます。フォーマットはTBS(To Be Specified)である。このフィールドの書式は拡張可能な形式である。最初の単語は、使用されている認可システムの指定である。

例

Authorization:例：Authorization: Bearer BtHKEsVs5mNNtNf7UWoVwjJzFqLOzucA
Accept-Language- Acceptと似て いますが、レスポンスで望ましいとされるLanguageの値をリストアップします。指定されていない言語での応答は違法ではありません。
User-Agent- この行が存在する場合、オリジナルのクライアントが使用したソフトウェア・プログラムを示します。これは統計的な目的とプロトコル違反の追跡のためです。含まれる必要があります。空白で区切られた最初の単語は、ソフトウェア製品名でなければならず、オプションでスラッシュとバージョン表記が必要です。ユーザーエージェントの一部を構成する他の製品は、別の単語として置くことができます。

例

ユーザーエージェントLII-Cello/1.0 libwww/2.5

Response Headers の例を見てみましょう。

Allowed- リクエストしているユーザーが、この URL に対して発行することが許されているリクエストのセットをリストアップします。このヘッダーラインが省略された場合、デフォルトで許可されるメソッドは "GET HEAD" です。
Public- Allowedbut と同様に、誰でも使うことができるリクエストをリストアップします。省略された場合、デフォルトは "GET" のみです。
Content-Length- ボディがバイナリであり、行の解析などを行わずに通信リンクから直接読み込むべきであることを暗示しています。データがリクエストの一部である場合、終了シーケンスのエスケープとデスケープを防ぐ。
Content-Encoding- 使用するエンコーディングメカニズムを指定する。現在は x-compressと x-gzipのみが 使用されています。
Content-Type- はドキュメントタイプを指定します。
Content-Length- 本文がバイナリであり、行の解析などを行わず、通信リンクから直接読み込むことを意味する。データがリクエストの一部である場合、終了シーケンスのエスケープとデスケープを防ぎます。
Last-Modified- オブジェクトの最終更新時刻、すなわちドキュメントが "生きたドキュメント "である場合には、このバージョンの日付。