Request-Responseヘッダーの使用方法

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

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

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

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

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

1_f12

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

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

2_getRequestHeaders

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

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

3_setResponseHeaders

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 - オブジェクトの最終更新時刻、すなわちドキュメントが "生きたドキュメント "である場合には、このバージョンの日付。