2021/04/26

HTTP関連問題判別

そのまた昔、セミナーで「Lotus Domino Webサーバーのパフォーマンス・チューニングと問題判別」というタイトルでお話をしました。最近 Notes/Domino 以外の Webプロジェクトで、予期せぬアプリ動作を調査する機会がありましたが、HTTP関連で予期せぬ動作があった場合、Domino で鍛えてきた技術者に出番があるのではないかな、と思い、少し書いてみます。もちろん、Domino Webアプリケーションでの問題判別にも有効です。

1. 覚えておきたいHTTP基礎知識

HTTP系で上手く動かない場合、デバッグなどをすると思いますが、その時に以下のことを知っておくと話が早いです。
- リクエストとレスポンスという概念があり、それぞれ「ヘッダー」と「ボディー」がある
- 認証系のデータは、主にリクエストヘッダーに乗る。Cookieに入ることが多い。
- レスポンスにはステータスコードがあり、200, 302, 304, 401, 403, 404, 500 くらいは知っておくと会話がしやすい
- HTTPS が使われるケースも多いので、SSL証明書に関する最低限の知識もあったほうがよい
- Origin/CORS関連。ブラウザからのGETリクエストに想定されるCookieがつかないこともあるので、知っておくとよい。

2.よくあるWebサーバー構成:

Webブラウザ(1) -- リバースプロキシ(2) -- Webアプリケーションサーバー(3)

という構成はよく見かけます。例えば
1: IE, Chrome, Firefoxなど。最近では場合によってスマートフォンなどからのアクセスもあり得ます。
2: ないケースもありますが、よくあるのは認証プロキシとしてTAM/ISAM/WebSealなどがあったり、Apache, Ingressなどが入るケースもあると思います。
3: Dominoなどですね

問題が発生した時は、1 で見えるものと、2 で見えるものと 3で見えるものが異なったりするので、それを意識しておきたいです。例えば:
- 1でトレースする内容と、3に届く内容は、2の動作によって異なる
- 2は内容を書き換えることがある
などがあります。特にHTTPヘッダは 2 と 3 で異なる部分が多いです。

3.よくあるデバッグ

アプリやWebサイトが上手く動作しない場合、例えばローカルや検証環境では動いていて本番では動作しない場合、多くはHTTPをトレースすることになると思います。トレース場所としては、ブラウザ(1)か、リバースプロキシ(2)か、Webアプリサーバー(3)か、ということになるかと思います。2, 3 は本番リクエストが流れることも多く、通常 1 でデバッグを取ることが多いと思いますが、1 で取得したデバッグは、必ずしも 3に流れてくるとは限らないので、疑わしい場合は2 や3でのデバッグも必要です。

1) Fiddlerを使ったデバッグ

Fiddler Classic | Original Web Capturing Tool for Windows

10年以上も前から王道ですが、ブラウザでのデバッグに比べても全部見れる安心感があります。ローカルのプロキシサーバーを書き換えるので、環境によっては向いていないところもあるかもしれませんし、また、HTTPSの場合は証明書の設定は必要です。

Fiddlerでのデバッグを行う時に、HTTPリクエストとレスポンスのヘッダとボディについてを理解していないと、読むのが大変だと思いますが、慣れてくると
- 本当にこういうリクエストは行われているのか?余計なリクエストが行われていないか?
- サーバーからのステータスコードはどうなっているのか
- サーバーからのステータスコードは、リクエストヘッダーに対して妥当なものか
- ブラウザはリクエストヘッダーに本当にCookieをつけているのか
- サーバーからのCookieはレスポンスヘッダーの中できちんとつけられているか
- サーバーからのレスポンスヘッダーで、キャッシュの扱いはどうなっているか
など、気になるところが見れるようになります。私の経験では、環境差での問題判別を行う時には、HTTPヘッダーの動作を見ることが多いです。

2) iPhone / iPad のブラウザのデバッグ

動作が iPad の Safari でアクセスした時だけ違う、ということがあるのですが、そういう時になかなかデバッグ出来ずに困っていたところ、やり方はあるようです。

Windowsで iOSのSafariのWebアプリをリモートデバッグする方法 - Qiita

ただし、現在のブラウザのタブを指定してデバッグを行うので、ブラウザ起動時の動作などは難しそうです。可能な限り、PC上のブラウザで再現させて、Fiddlerで取得してしまったほうが私はラクでしたが、iOSのみで再現する現象をトレースする時には心強いです。

なお、iOS用のデバッグプロキシとして、Charles という有料ソフトがあるようです。
PC接続してのデバッグだけではどうしても難しいことがあり、やはりローカルプロキシでがっつりと内容を取得したい場合があるので、そういう時に便利だと思います。
(私も少し触ってみましたが、プロキシ用のローカル証明書の設定ページへのアクセスが切れていて、HTTPS必須アクセスでデバッグしたかったところ断念しました。)

やはりHTTPヘッダーが見れると、嬉しいですね。

4. その他 Tips

Webサーバーの動作を試すためにも、自由にHTTPリクエストを発行出来る環境があると便利なので、curl や REST Client があると便利ですね。
(多分 Fiddler に、いろいろと使いこなせない便利な機能があると思います)

1 件のコメント:

匿名 さんのコメント...

助かりました。ありがとうございます。
htmlに関してタイムアウト現象が発生しがちなのですが、回避策と理由について説明したいけれどどうにも説明しきれない・・・うまいことないものかと考えていたところこの記事にたどりつきました。
本当に助かりました。