アカウント名:
パスワード:
chanbaba さんが気にしていて、#987588 の Anonymous Coward さんが気にしていないのは、HTTP サーバとブラウザ間のプロトコルのレベルで Cookie の値が ASCII に制限されていないかどうか。
仕様を読むと、手順を踏めば、RAW BINARY を流せるように見えます。
ただ、この話が #987588 の Anonymous Coward さんの望みどおりか、ちょっと心配です。私も Cookie の値に quoted-string なんて使ったことがありません。
あ、本当にバグ報告済みでした。
Bug 13029 - Win32 mod_cgi failure with non-ASCII characters in env var [apache.org]
Win32 環境での環境変数を作成する際にコード変換が入っているようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
1.xのWin32 Binary (スコア:0)
1.3.36もなかった様に思いますし……
2.xに移行せず、自前でコンパイルもしない人は、1.3.35を使い続ける事になって、危険な様な……
#つか、2.x(Win32)でURLエンコードされてないCookieが化けるBug、修正されないかなぁ……
Re:1.xのWin32 Binary (スコア:0)
使っちゃいけない文字をエンコードしないで使ったら化けても文句は言えないと思うけど。バグってるのは apache じゃなくてそういう cookie を吐いてるスクリプトの方でしょ。
Re:1.xのWin32 Binary (スコア:0)
エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
#サーバOSを変更しろ、Win32なら素直にMS-IIS使えって意見もあるだろうけど(汗)
#つか、Unix版でも、Apache2.0.xの初期の頃は化けてた気がするし、直したのならBugと認識したって事でしょう?#Win32だけ放置なのは、なんだかなぁ。RFC違反って事で、全プラットフォーム問答無用で化けて同じ動作なら、納得も行くんだがねぇ。
Re:1.xのWin32 Binary (スコア:4, 参考になる)
出回っていても2.0系が出てから結構立つんだし、まだ直していないのが問題なんじゃないの?
と言うか、出回っていたって、メンテが終わった奴だろ。メンテが続けられているのならばとっくに直っているはず。
俺は最近は見たこと無いな、日本語クッキーは。
とほほのCookie入門でも
>日本語を使用する際にはそれぞれ、%3B、%2C、%20のようにエンコードして記述しなくてはなりません。
http://pzxa85.hp.infoseek.co.jp/www/wwwcook.htm
と%エンコード必須みたいだぞ。
ネットスケープのクッ
Re:1.xのWin32 Binary (スコア:1, すばらしい洞察)
何処からそう言う話が出て来たんでしょうか? AddDefaultCharsetをoff以外にすると、他の文字コードなベージが提供し辛くなって、不便なだけですし、関係ありません。
#もし、CGI側とWebブラウザ側で異なる文字コードを喋っているのなら、其れはApacheの責任では無いでしょう?
>2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの?
いえ、2.2.2(Win32)で再現する所までは確認しています。問題は無くなっていません。
どうやら、Webブラウザに格納されたCookieを見て、化けていないと判断されている様ですが、残念ながら問題は其処ではありません。
Cookieが化けるのは、Apacheから見て送信時ではなく受信の時です。
私は、IEではなく、Gecko系のWebブラウザでしか試してませんので、IEでの結果は知りませんが
仮に、問題のCGIがShift_JISなBBSだったとしてと、投稿者名の欄に「日本語文字列」と入力して投稿しますと
(Gecko系)Webブラウザの「cookies.txt」にS-JISで「日本語文字列」と格納され、此の時点では文字化けは起きていません。
問題は此処から先でして、此の状態で先程のBBSを訪問すると、投稿者名の欄が文字化けを起こしています。
此のまま、投稿者名を変更せず投稿しますと、投稿者名の化けた書き込みが投稿され、当然ですがWebブラウザに格納されたCookieも、文字化けしたもので上書きされる事になります。
と云う事で、Apache2.x(Win32)が受信したエンコードされていないCookieを、CGI等が取得すると内容が壊れている。と云う事です。
1.3.35(Win32)では、問題ありません。確か、Netscape4.xでも再現したと思います。(IEでは知らない)
WebブラウザがApacheに送信した内容の所で止まっていては、問題は発見出来ません。
問題は其の先のCGIで取得する所です。
#何やら「(スコア:4, 参考になる)」なんてモデレートがなされていますが、私からしますと「(スコア:0, 見識が足りない)」と云った感じです。(スコア:-1と迄は云いませんが……)
Webサーバは、クライアントから受信したCookieデータを、サイズオーバーでない限りは、素直に(バイナリ扱いで)其のまんまCGI等に渡してくれるのが良いと私は思うんですけどねぇ。
其処から先の動作は、CGIとクライアントの責任だと思うので。
Cookie に any OCTET を書けるか (スコア:1)
chanbaba さんが気にしていて、#987588 の Anonymous Coward さんが気にしていないのは、HTTP サーバとブラウザ間のプロトコルのレベルで Cookie の値が ASCII に制限されていないかどうか。
仕様を読むと、手順を踏めば、RAW BINARY を流せるように見えます。
ただ、この話が #987588 の Anonymous Coward さんの望みどおりか、ちょっと心配です。私も Cookie の値に quoted-string なんて使ったことがありません。
Re:1.xのWin32 Binary (スコア:1)
あ、本当にバグ報告済みでした。
Bug 13029 - Win32 mod_cgi failure with non-ASCII characters in env var [apache.org]
Win32 環境での環境変数を作成する際にコード変換が入っているようです。
Re:1.xのWin32 Binary (スコア:1)
>何処からそう言う話が出て来たんでしょうか? AddDefaultCharsetをoff以外にすると、他の文字コードなベージが提供し辛くなって、不便なだけですし、関係ありません。
>#もし、CGI側とWebブラウザ側で異なる文字コードを喋っているのなら、其れはApacheの責任では無いでしょう?
あのー、何処が原因で文字化けするのか分からないのですよね?あれが原因で、ソースのここをこう修正すれば直るとか詳しく認識しているの?
「みたく」とは、「この様にしろ」と言う意味で無い事は解っていますか?
#987147は
>まぁ、CGI側が正しくないのは確かなんだが、Apache1.3.xと挙動が異なるってのと、Unix版では化けないって事で、Apacheに問題が無いとも云えん様な。
>エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
と言っていたから、「CGIを弄りたくない」と言う前提があるので、使っている文字コードをCGIで指定していなければ、指定した方が文字化けし難いと判断して、チェック箇所として提案したら、「不便なだけですし、関係ありません」って何それ。
全然的外れのアドバイスで役に立たない邪魔な存在の様な表現ですよね。
原因が解っているのならば、具体的に述べたり、開発している人達に連絡するなり、自分で修正するなりすれば良いんじゃないの?
「Win32だけ放置」と、「放置されている」と言う認識なんでしょ?
何が引き金になっているか解らないからこそ、Charsetとかの話をしたりするのは当然の流れでは?
CGIを弄らないでCharsetをするには、俺のアドバイスは結構良いと思うけど。
>>2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの?
>いえ、2.2.2(Win32)で再現する所までは確認しています。問題は無くなっていません。
>どうやら、Webブラウザに格納されたCookieを見て、化けていないと判断されている様ですが、残念ながら問題は其処ではありません。
IEとapacheの間に串を挟んで、串を通るデータを見てます。
と言うか、HTTPのリクエストとレスポンスのログにしか見えないはずなんだけど....
>Cookieが化けるのは、Apacheから見て送信時ではなく受信の時です。
それを言わないで、Charsetは関係無いとか言い出しているのは理解出来ないよ。
>#! ruby -Ks
>STDOUT.binmode
>print "Content-type: text/html\r\n"
>print "Set-Cookie: 日本語=文字化け\r\n"
>print "\r\n"
>ENV.each do |key, value|
> print key, " => ", value, "
\r\n"
>end
とやったら、
>HTTP_COOKIE => ?u?{?e=?¶???≫? ̄
と化けてるな。
>#! ruby -Ku
と
>print "Content-type: text/html; charset=UTF-8\r\n"
を変えたら、
>HTTP_COOKIE => ?u?{?e=?????P; a?\a???a?=a??a-?a??a??
エディタで文字コード変えて読んでも駄目だな。
>#! ruby -Ke
と
>print "Content-type: text/html; charset=euc-jp\r\n"
を変えたら、
>HTTP_COOKIE => ?u?{?e=?・゚??≪= ̄; a?\a?&ca?=a??a-?a??a??
と、1個足りない.....
>#何やら「(スコア:4, 参考になる)」なんてモデレートがなされていますが、私からしますと「(スコア:0, 見識が足りない)」と云った感じです。(スコア:-1と迄は云いませんが……)
>
>Webサーバは、クライアントから受信したCookieデータを、サイズオーバーでない限りは、素直に(バイナリ扱いで)其のまんまCGI等に渡してくれるのが良いと私は思うんですけどねぇ。
>其処から先の動作は、CGIとクライアントの責任だと思うので。
アスキー以外を使うのがおかしいのだしさ。そして、「apacheがCGIに渡すところ」なんて一言も言われてなかったのにこの言われようかよ。
あと、安定性を考えるとやはり%エンコードした方が良いよ。
「他の文字コードなベージが提供し辛くなって」と言う考えがある以上、文字コードの統一が図れていないのだろ。
クッキーはサブドメインや下位ディレクトリーにも流れるし、HTTPリクエストに普通文字コード情報は無いし、ブラウザ側の実装で違ったりするかも知れないだろ。
HTTPヘッダーは環境変数に入れる為に、複数行に別れている奴や同じ名前のヘッダーは加工して入れたりするのだろ?