Windowsマシンで仕事をしていた以前の仕事では、HTTPトランザクションの表示とデバッグのために Fiddler を使用していましたが、今は特に、サイトが期待通りに動作しているかどうかを確認するために、取り組んでいるajaxサイトのHTTPトランザクションを監視したいと思っています。HTTPの書き換え（Fiddlerで提供されている）は必要不可欠なものではありません。
Chromeを使用して、chrome://net-internals/
詳細な分析とダンプを可能にします。
Charles Proxy ](http://www.charlesproxy.com/)を見つけました。Fiddlerの機能にかなり近いですね。無料ではありませんが、値段の価値はあるかもしれません。
トラフィックを監視するための私のお気に入りのmacアプリは、 HTTPScoop で、コマンドラインからtcpdumpを使用するだけでなく、 昨年ブログに書いたこの記事 で詳しく説明しています。
ご質問の内容とは異なりますが、FirefoxではLive HTTP Headersアドオンが、URLやHTTPメソッドの変更を含むリクエストを編集したり再生したりしたい場合に必要なすべてのものです。同様に、Safariでは、組み込みのWebインスペクタのリソースペインが私のニーズのほとんどをカバーしています。(環境設定でWebインスペクタを有効にする。メニューバーに開発メニューを表示する_)。ChromeやFirefoxにも似たようなツールがありますが、もっと複雑になると、 Wireshark のパケットスニッファーを起動します。しかし、Fiddlerと違ってWiresharkはデータを変更することができませんし、Fiddlerのようにオートレスポンダのようなものをサポートしていません。
Wiresharkについては、一般的なHTTPキャプチャ情報についてはHyper Text Transfer Protocol (HTTP)、displayフィルターの例についてはHTTP Packet Capturing to debug Apacheを参照してください。(capture フィルタを “port 80” に設定して、そのポートへの全てのリクエストとそのポートからのレスポンスを表示したいかもしれません。あるいは、いくつかのサーバに限定したい場合は、 captureフィルタを"port 80 and host www.google.com “に設定するとよいでしょう)。例えば:
# Show only 404: page not found http.response.code == 404 # Show only certain HTTP methods http.request.method == "POST" || http.request.method == "PUT" # Show only javascript http.content\_type contains "javascript"
Wireshark は gzip を解凍したり、エンコードされた(圧縮された)ものをその場で解凍したりすることができることに注意してください。ほとんどのウェブサーバはブラウザに送信するデータを圧縮してくれるので、これを使うと読みやすくなります。
(オートレスポンダについては: 優れた JS Bin に Ajax リクエストのデバッグに使う方法の短いビデオがあります。JS Bin を知らない場合は、まず紹介ビデオを見てください)
Charles(既出)の他に、私はMozilla Firefox用の* HttpFox ** アドオンも気に入っています。Charles と同様に Mac と Windows の両方で使えます。ブラウザの中に常駐しているので、Charles よりも軽量で、迅速なトラブルシューティングに便利です。ここでは HttpFox のページからいくつかの情報です:
HttpFox はブラウザとウェブサーバ間のすべての着信と発信 HTTP トラフィックを監視し、分析します。
それは、HttpWatch や IEInspector のようなツールから知られている機能を Firefox ブラウザにもたらすことを目指しています。
リクエストごとに利用可能な情報が含まれています:
- リクエストとレスポンスヘッダー
- 送信と受信クッキー
- Querystring パラメータ
- POST パラメータ
- レスポンスボディ
そして、スクリーンショット:
プロキシではありませんが、HTTPのデバッグに役立ちます:
単にHTTPトラフィックを持つことになるインターフェイス上でスキャンを開始し、トラフィックを実行してからスキャンを停止し、フィルタ文字列として “HTTP "と入力します。これで、HTTP 会話のすべてのパケットを検査することができます。パケットの詳細ビューを開いて、HTTPセクションを開くことができ、それはパケットの間に開いたままになります。
それはあなたがブラウザのプロキシを変更する必要はありませんそれは持っている素晴らしいツールです。一方、それは暗号化されているので、HTTPSトラフィックを助けることはできません。(ただし、それは RSAを使用してSSL接続を復号化することができます)
遅くなりましたが- Paros Proxy を使っています。Javaなので、クロスプラットフォームです。もしアプリとしてパッケージ化されている方がいいなら、一番下に ここ があります。
Burp Suiteも忘れずに。無料版があります。クロスプラットフォームです。 http://portswigger.net/burp/
Fiddler for Mac](http://fiddler2.com/documentation/Configure-Fiddler/Tasks/ConfigureForMac) は Parallels のサイトの指示に従って簡単に設定できます。
唯一の注意点は、VM の IP アドレスを指すようにネットワーク設定を手動で設定しなければならないことですが、それほど大きな問題ではありません。
無料の GlimmerBlocker がトリックの一部を行うことができるようです。
もちろん、これはあらゆる種類のコンテンツをブロックし、ブラウザがそれを受け取る前に 応答を変換 することができます。しかし、実際にはリクエストとレスポンスの両方を変更することができます。そして、真のデバッグではありませんが、それはまた、ログを提供しています。したがって、 基本的なニーズ には適しているかもしれません:
GlimmerBlocker の内部で動作するスクリプトは 4 種類あり、いくつかのオブジェクトはスクリプトタイプの一部に対してのみ定義されています:
- global proxy: グローバルプロキシの設定を行います。 > - リクエストの変更: リクエストされたURLを変更したり、リダイレクトレスポンスをブラウザに返したり、テキスト/htmlをブラウザに返したりすることができます。Safariのみ、AvB]
- 変換: Safari[またはGlimmerBlockerによって提供されるプロキシを使用するように設定されているブラウザ、AvB]に送信される前に、ウェブサーバによって受信された応答を変更します。
(また、Greasemonkeyアドオンを使用せずに、Greasemonkeyアドオンを使用せずに、受信された応答に様々なGreasemonkeyスクリプトを含めるためにそれを使用することができます、フラッシュをブロックするのように、アドオンをインストールせずに)。
公共のインターネットを経由するアプリのトラフィックやサードパーティのAPI統合を扱っている場合、Runscope（完全に開示しますが、私は共同設立者です）を試してみてください。Runscope は任意の URL への HTTP リクエストをキャプチャし、デバッグのための素晴らしいストリームビューを提供し、個々のリクエストを他の人と簡単に共有することができます。
Cocoa Packet Analyzer ](http://www.tastycocoabytes.com/cpa/ “Native Mac OS X implementation of a network protocol analyzer and packet sniffer.”)はとても参考になります。
また、 APIKitchen を試してみるのもいいでしょう。HTTP APIや一般的なリクエストのデバッグやテストに役立ちます。また、内部ネットワークでテストするためのオフライン版もあります。インストールは不要です。