ブラウザーが送った内容と、サーバーの返事を読む

不具合の調査では、どこへ何を送り、どの番号と本文が返ったかを分けて読みます。本文では検索や出力依頼も例として説明します。今回の端末実習は、自分のHTTPサーバーからページを受け取り、ヘッダーの変更を端末とブラウザーで比較する一つの課題です。

ブラウザーなど、処理を頼むアプリをクライアントと呼びます。頼まれた処理を行い結果を返す側がサーバーです。機械の種類ではなく、そのやり取りでの役割を表します。同じパソコンの中に、両方が動くこともあります。

処理を頼むメッセージが要求、返事が応答です。今回は、練習用のAPIという窓口へ要求を送ります。外部のサイトへ自由にアクセスする練習ではありません。

サーバーも、データベースへ検索を頼むときは、頼む側になります。画面の入力欄を隠しても要求を作って送れるため、サーバーは入力の形式、利用者、操作の許可をそれぞれ確認します。JSONとして読めることと、操作してよいことは別です。

URLは、ページや機能を指定する住所のような文字列です。通信方法、ホスト名、パス、クエリ、フラグメントに分けて読みます。ホスト名の後ろにポート番号を付けることもあります。

https://sample.example.test:8443/catalog?title=Blue#detailsなら、httpsが通信方法、sample.example.testが相手のホスト名、8443がポート番号、/catalogが機能の場所です。?以降は検索条件、#以降は主に画面側で使う位置の指定です。通信方法・ホスト・ポートの組をoriginと呼びます。接続する相手を表すoriginと、その相手に頼む場所や検索条件を分けて読みます。

パスだけが変わってもoriginは同じです。一方、ポート8443と443は違います。名前から通信先を探すDNS、相手と暗号化した通信を確かめるTLS、アプリが操作を許す判断も、それぞれ別の段階です。

URLの検索条件では、title=Blue&tag=webの&が項目の区切りになります。検索したい名前そのものに&が入っている場合、そのまま書くと区切りと取り違えられます。

値の&は%26、値の+は%2Bなどの表し方に変えます。これをURLエンコードといいます。URLSearchParamsで扱う検索条件では、+は空白として扱われます。URL全体をまとめて変えるのではなく、検索する値の部分を正しく表します。tagを二つ送りたい場合は、片方で上書きせず、両方を残します。

コードでURLSearchParamsを使う場合、set("title", "Blue & Green")で検索語を値として設定できます。このAPIでは空白を+で表し、相手が読むと空白へ戻ります。tagを二つ残すにはappendを二回使います。setを二回使うと前の値を置き換えます。getは最初の値、getAllは同じ項目名の値をすべて取り出します。複数のtagのすべてに合う書類を返すのか、一つでも合えばよいのかは、相手のAPIの仕様で確認します。今回の端末実習では検索条件を編集せず、返事のヘッダーを比較します。

/catalog?title=Blue#detailsの#detailsはフラグメントです。通常はブラウザーが画面内の位置を扱うために使い、HTTPで送るパスと検索条件には含めません。&のつもりで#を書くと、その後ろの値がサーバーへ届かなくなる場合があります。

JavaScriptが#以降を読み別の要求へ入れることはできます。秘密の安全な保管場所とは考えません。Networkの要求URLを見れば、画面のURLと送信した内容を分けられます。以前の例のobserved.targetという入力・結果欄は、現在の端末実習では使いません。

要求にはGETやPOSTという操作名、パス、ヘッダー、必要に応じて本文があります。ヘッダーは本文の形式などを伝える追加情報です。GETは情報の取得、POSTはデータを送って処理を頼む場合などに使います。

JSONの本文を送る例ではContent-Typeにapplication/jsonと書き、本文もJSONの形式と業務の条件に合わせます。POSTという名前だけで暗号化や権限の確認は行われません。今回の端末実習はページのGETを観察します。出力ジョブを作るPOSTや検索タグの操作は、この課題の手順にはありません。

200は要求の成功を表しますが、欲しい内容が返ったかは本文を見ます。202は受付を表し、保存や出力の完了を保証しません。400は要求の誤り、405は使えない操作名、415は扱えない本文の形式、422は内容を処理できない場合などに使います。404は対象が見つからない場合などの番号です。

これらの細かい使い分けはサービスの仕様で確認します。今回の実習では存在するページの200と、存在しないページの404を比べます。他の番号をこの実習で全部発生させる必要はありません。

404などが返れば相手は要求に返事をしています。通信が切れて応答を受け取れない場合とは違います。返事がないことから、相手が何もしていないと断定できません。注文などの再送前には受付番号や処理記録で確認します。

JavaScriptのfetchは404でも通常Responseという応答を返します。statusやokと本文を分けて読みます。今回はPythonとブラウザーで同じHTTPサーバーへ要求します。実注文や出力ジョブは作りません。

config.jsonのheadersはサーバーの返事へ付ける情報です。exercise.pyを実行すると、ページ取得と存在しないページへの要求を行い、result.jsonに結果を残します。--browser付きで起動するとブラウザーから観察できます。

最初の結果を記録してからX-Lessonの値を変更し、同じ二通りの観察を行います。NetworkのResponse Headersとresult.jsonの「独自ヘッダー」が同じ変更を示すか確認します。URLの検索値やPOST本文の説明は他の通信を読む際にも使う知識ですが、今回の提出はこの一つの実習だけです。

最初に送信先、パス、操作の種類を確認します。次に検索する値や本文の形式、最後に応答の番号と本文を見ます。一か所直してもう一度送り、何が変わったか比べます。

この練習で分かるのは、指定した要求と応答の関係です。通信の暗号化、ログインの仕組み、他人のデータを返さない判断、実際の出力処理が終わったかは、それぞれ別に確かめます。

実際の調査では、ブラウザーの開発者ツールにあるNetworkで、送信先、メソッド、検索条件、ヘッダー、本文、応答、時刻、要求IDを比べます。Cookieやトークンを記録へそのまま貼らず、秘密を含まない必要最小限の再現手順にします。Cookieを送る条件、CORSによる読取りの制限、CSRF、キャッシュ、TLS、実ジョブの完了確認は、今回の練習とは別に調べる内容です。