wgetを-Sオプションつきで呼び出すのもいいけれど、このとき画面に出力された内容がwgetによって加工されていないとも限らない。httpヘッダを覗く最もプリミティブな方法はtelnetを使う方法である。コマンドラインから下のようにコマンドを叩く。最後に2回改行するのを忘れない。あと、改行はCR+LFで送信するように設定。cgiのエラーは標準出力に出力されるので(多分)、受信するレスポンスヘッダ以降にエラー内容が書き込まれる(多分)。-w付きでcgiを起動させると結構エラーが出る。これをこまめに直すのも一興。
telnet za.toypark.in 80 GET /cgi-bin/foo/bar.cgi?foo+bar HTTP/1.0 Host: za.toypark.in
ここまで書いておいて不親切だと思ったので追記。サーバが受け付ける漢字コードがどんなものか知っているといいけどこれはほとんど問題ではないだろう。つまり僕らが入力した内容をどのような漢字コードでサーバに送出するかという点だ。なぜなら、僕らはいわゆるASCIIコードで定義された文字しか使わないから。UnicodeにせよEUCにせよShift_JISにせよ、多くのコード体系ではASCIIコードを踏襲している、言い換えれば、コード体系の最初の128文字はASCIIコードと被っているということだ。漢字コードの設定が意味を持っている例は、telnetサービスを供給しているサーバで仮想端末からemacsとかviを使って日本語を入力する場合である。
次の注意点はサーバから送られてきたデータの漢字コードである。先に述べたのと同様に、僕らがサーバから受け取った内容が全てASCIIコードの範囲だったら受け取り漢字コードに注意する必要はほとんどないといってもいいだろう。ただし日本語が含まれる結果を出力するcgiを仮想端末で受け取る場合はその結果に即した文字コードを受け取り文字コードとして設定しなければいけない。ブラウザは受け取ったデータから勝手に文字コードを判定して、結果に即した文字コードに変えてくれるからブラウザで受け取り文字コードを明示的に設定する必要はなかったわけだ。どちらにせよここの設定は受けとったデータをどのような漢字コードで書かれたデータと解釈するかという設定である。だから、クライアントが解釈できない文字コードを受け取った場合は、端末にブラウザで表示されるような文字は見えず、文字化けして見える。たとえば、Tera TermはJIS、Shift_JIS、EUC、に対応しているが、Unicodeには対応していないためUTF-8で書かれたWebページを上記の方法で取得しても文字化けして見える。
もう一つ忘れてはいけないことがあった。それは送出改行コードと受け取り改行コードの設定だ。上で送出改行はCR+LFにしろと書いたけど、これには理由があるんだ。理由はhttpの勧告文書にそう書いてあったから。つまり標準化を押し進める団体がそうしろといっているからで、多くのwebサーバはその規格に準拠するように作られているからだ。長いものには巻かれろってことかな。受け取り漢字コードはサーバが送ってきた改行コードを僕らがどう解釈するかという話なんだけど、ここの設定はあまり気にする必要はないと思う。多分、さっき言った標準化団体はサーバから送出されて僕らが受け取るデータも改行コードはCR+LFに決めていたと思う。だから、設定はCR+LFでいいんじゃないかなと思う。