うちのサーバーのLocationが変なのですが

[上に] [前に] [次に]
Syuichi.K [HomePage] 2000/05/15(月) 05:06:33
私は
http://www.shirakami.or.jp/
というプロバイダのサーバーにてHPを運営しています。

その中でCGIロケーションを使う機会がけっこうあるのですが、Netscapeブラウザでのみ飛んだ先のページが妙な文字化けを起こすのです。
通常のページを"ISO-8859-1"で閲覧したかのような表示になり、一度その状態で読み込んでしまうとブラウザの設定で文字コードを設定し直しても解消されません。更には再読み込みしてもなぜか解消されません(キャッシュが効き過ぎている・・・？)。
飛んだ先のページは選びません。

この現象が始まった時期にちょうどサーバーがapache1.3.12に更新していたそうなので、関係あるかと思います。

ブラウザですが、WinN4.?/MacN4.5辺りでこの現象を確認しています。複数のサイト来訪者が文字化けについて報告して来ました。
N6.0 PR1では発生しなかったそうです。

サーバー管理者にも4月末に問いあわせたのですが、未だ解決されていないようです。

ディレクトリを指定する時スラッシュ(/)を付け忘れると、スラッシュ付きのURLを同じ形式のロケーションでブラウザに渡しますね。その時も同じ問題が起こります。
このURLを参照すると、
http://www.shirakami.or.jp/~kouiki/kanko1
このURLにジャンプして、
http://www.shirakami.or.jp/~kouiki/kanko1/
そのページが化けます。（ここは私と無関係のページですが引用して問題ない所かと思います）

また、簡単なDEMOが
http://www.shirakami.or.jp/~digiart/cgi-bin/DEMO/
にあります。フォーム入力をLocationで飛ばすだけです。
shirakami以外のサーバーのどこのページに飛んでも化けます。

---
説明が長々となってしまいましたが・・・
HP作成に関する質問という事なので、とりあえず個人的にこの問題を回避する方法はないでしょうか？（CGIでおまじないを出力する　というような感じ・・・？）
またできれば、サーバー全体で解決する方法がわかればいいのですが・・・。
B-Cus 2000/05/15(月) 06:31:52
http://www.shirakami.or.jp/~kouiki/kanko1 を読んだとき、
　HTTP/1.1 301 Moved Permanently
　Date: Sun, 14 May 2000 21:26:31 GMT
　Server: Apache/1.3.12 (Unix)
　Location: http://www.shirakami.or.jp/~kouiki/kanko1/
　Connection: close
　Content-Type: text/html; charset=iso-8859-1
となっているので、charset=iso-8859-1 を消すように管理者に頼む、と。

個人的に直すなら、.htaccess に
　ErrorDocument 301 /~foo/301.cgi
として、301.cgi の中で
　print <<END;
　Location: $ENV{REQUEST_URI}/ (ここらへん適当)
　Content-Type: text/html
　END
　exit;
かな。動作確認はしてません。
Syuichi.K(投稿者) 2000/05/15(月) 07:41:33
B-Cusさん、ありがとうございます。
前半部分を管理者にメールしてみます。
htaccessはサーバー設定で使えないようになっているようなので。
（それ以前に内容もなかなか理解できない・・・）

#やっぱりここに来る人達は違うなぁ。
H&A [E-Mail] [HomePage] 2000/05/15(月) 14:32:19
B-Cus さん：
> 　Content-Type: text/html; charset=iso-8859-1
> となっているので、charset=iso-8859-1 を消すように管理者に頼む、と。

この "charset=iso-8859-1" は「リダイレクト先のリソースで使われている符号化文字集合」ではなく、「"301 Moved Permanently" レスポンスで使われている符号化文字集合」です。
http://www.shirakami.or.jp/~kouiki/kanko1 のリクエストへのレスポンスには ISO-8859-1 で規定されている符号化文字しか使用されていないので、"charset=iso-8859-1" と指定されていることは間違いではないと思います。

文字化けの原因は、「http://www.shirakami.or.jp/~kouiki/kanko1/ のリクエストへのレスポンスに charset 指定がない」というところにあるのではないでしょうか。
HTTP/1.1 (RFC2616) の 3.7.1 を見ると、charset 指定のないリソースについては ISO-8859-1 とみなすよう記述されています。
Netscape Navigator はこの規定に従ったか、あるいは符号化文字集合指定のないレスポンスを「直前に指定された符号化文字集合と同じ符号化文字集合である」と推定しているのだと思います。

ということで、解決方法としては…「ISO-8859-1 以外の符号化文字集合を使用したリソースの HTTP レスポンス中には必ず charset を入れるようにする」しかないのではないでしょうか。
サーバに Apache を使用していて、.htaccess で AddType ディレクティブが使用できるのであれば個人的に解決することもできますが、.htaccess が使用できないとなると管理者にしか解決できないと思います。
…やっぱり「管理者にメール」になってしまいますね。

Syuichi.K さん：
> この現象が始まった時期にちょうどサーバーがapache1.3.12に更新していたそうなので、関係あるかと思います。

http://www.apache.org/dist/CHANGES を見ると、Apache 1.3.12 では

>   *) Add an explicit charset=iso-8859-1 to pages generated by
>      ap_send_error_response(), such as the default 404 page.
>      [Marc Slemko]

としてエラーレスポンスに charset 指定を付与するようになったそうです。おそらく、これが関係しているのでしょう。
B-Cus 2000/05/15(月) 14:47:45
> HTTP/1.1 (RFC2616) の 3.7.1 を見ると、charset 指定のない
> リソースについては ISO-8859-1 とみなすよう記述されています。
んー、実装もその通りになっていましたっけ。HTTP/1.1 で、
charset なしのレスポンスは結構あると思うので (apache って
HTTP/1.0 でリクエストしても HTTP/1.1 で返しませんっけ?)、
301 の charset=iso-8859-1 を、NN/NC のバグのせいで次ページ
にも引きずってしまったのが原因かと思ったのですが

> 解決方法としては…「ISO-8859-1 以外の符号化文字集合を
> 使用したリソースの HTTP レスポンス中には必ず charset を
> 入れるようにする」しかないのではないでしょうか。
でも、これって厳しくないですか? .html と言っても
EUC/SJIS/ISO-2022-JP があるわけで。
H&A [E-Mail] [HomePage] 2000/05/15(月) 15:13:50
B-Cus さん：
> > HTTP/1.1 (RFC2616) の 3.7.1 を見ると、charset 指定のない
> > リソースについては ISO-8859-1 とみなすよう記述されています。
> んー、実装もその通りになっていましたっけ。HTTP/1.1 で、
> charset なしのレスポンスは結構あると思うので (apache って
> HTTP/1.0 でリクエストしても HTTP/1.1 で返しませんっけ?)、
> 301 の charset=iso-8859-1 を、NN/NC のバグのせいで次ページ
> にも引きずってしまったのが原因かと思ったのですが

Internet Explorer や Netscape Navigator などの実装がどのようになっているかは私にはわかりませんが、おそらく「NN/NC のバグのせい」というのは正しいと思います。
Netscape Navigator 3.03 や 4.7 で試してみたところ、リダイレクト後の HTTP レスポンスに charset 指定はなかったのにもかかわらず「ページ情報」で表示される文字セットは iso-8859-1 となっていました。

HTTP/1.0 (RFC1945) にも

> When no explicit charset
> parameter is provided by the sender, media subtypes of the "text"
> type are defined to have a default charset value of "ISO-8859-1" when
> received via HTTP.

と記述されているので、ある意味間違いといえなくはない…のかもしれませんが…
"default" と書いてある以上、ユーザが変更できるようにするべきだとも思えますね。

> でも、これって厳しくないですか? .html と言っても
> EUC/SJIS/ISO-2022-JP があるわけで。

確かに、日本語のリソースで使われる符号化文字集合は何種類もありますからねぇ。
さまざまな Author によるリソースが混在しているサーバでは、Author が自分のリソースの符号化文字集合を明記するために .htaccess 中での AddType ディレクティブを使用するのが一番簡単だと思います。

# MultiViews などを使うと、拡張子を ".html.jis" 等にすることで符号化文字集合を指定できるのですが

管理者の方に、.htaccess 中での AddType を使用できるよう要請してみてはいかがでしょうか＞Syuichi.K さん
H&A [E-Mail] [HomePage] 2000/05/15(月) 15:17:19
> と記述されているので、ある意味間違いといえなくはない…のかもしれませんが…

「正しいといえなくはない…」の間違いですね。
B-Cus 2000/05/15(月) 21:43:42
http://apacheml.ecc.u-tokyo.ac.jp/cgi-bin/namazu.cgi?key=iso-8859-1&whence=0&max=20&format=long&sort=score
http://apacheml.ecc.u-tokyo.ac.jp/ml/msg04049.html
B-Cus 2000/05/15(月) 23:10:04
一応まとめておくと (apache の偉い人に教えてもらったことも含む)、
　- CERT Advisory が出た (http://www.cert.org/tech_tips/malicious_code_mitigation.html#3)
　- それに伴い、apache-1.3.12 で、301 Moved parently などに charset=iso-8859-1 を付けるようにした
　- その結果、301 の charset を引きずるという NN/NC のバグが顕在化し、困った困った。
というわけで、サーバ側の対処としては
　- apache のソースをいじるしかない。iso-8859-1 の部分はハードコーディング
　　されているので、AddDefaultCharset では対応できない。
　　http://apacheml.ecc.u-tokyo.ac.jp/ml/msg04049.html
ユーザ側の対処としては、
　- 各ページに必ず charset を付ける (META でもいいのかな?)
　- .htaccess で AddCharset や AddType を設定する
ってな感じでしょうか。

詳しくは先程示したポインタを参照のこと。
[上に] [前に] [次に]