パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Apache相次いでリリース」記事へのコメント

  • by Anonymous Coward on 2006年07月30日 0時11分 (#987116)
    Apache1.xのWin32 Binaryは、もう提供されないのでしょうか?
    1.3.36もなかった様に思いますし……
    2.xに移行せず、自前でコンパイルもしない人は、1.3.35を使い続ける事になって、危険な様な……
    #つか、2.x(Win32)でURLエンコードされてないCookieが化けるBug、修正されないかなぁ……
    • Re:1.xのWin32 Binary (スコア:2, 参考になる)

      by Anonymous Coward on 2006年07月30日 1時45分 (#987160)
      これ [apache.org]ですか?
      親コメント
      • by Anonymous Coward on 2006年07月30日 23時13分 (#987536)
        これ [apache.org]ですか?
        おぉ、Apache.orgにArchive of public software releases [apache.org]なんて所があったんですね。
        情報、有り難う御座います。
        www.apache.org/dist/ [apache.org]以下しか探して無かったので見付けられませんでした。
        以前あったoldディレクトリも何時の間にか無くなったし……
        archive.apache.org/ [apache.org]に移動したって事でしょうか?

        #でも、1.3.36の公式Win32Binaryは、結局出なかったみたいですね。
        #Security fixじゃないから出なかったって事ですかねぇ。
        親コメント
    • by Anonymous Coward
      >#つか、2.x(Win32)でURLエンコードされてないCookieが化けるBug、修正されないかなぁ……

      使っちゃいけない文字をエンコードしないで使ったら化けても文句は言えないと思うけど。バグってるのは apache じゃなくてそういう cookie を吐いてるスクリプトの方でしょ。
      • by Anonymous Coward
        まぁ、CGI側が正しくないのは確かなんだが、Apache1.3.xと挙動が異なるってのと、Unix版では化けないって事で、Apacheに問題が無いとも云えん様な。
        エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
        #サーバOSを変更しろ、Win32なら素直にMS-IIS使えって意見もあるだろうけど(汗)
        #つか、Unix版でも、Apache2.0.xの初期の頃は化けてた気がするし、直したのならBugと認識したって事でしょう?#Win32だけ放置なのは、なんだかなぁ。RFC違反って事で、全プラットフォーム問答無用で化けて同じ動作なら、納得も行くんだがねぇ。
        • Re:1.xのWin32 Binary (スコア:4, 参考になる)

          by chanbaba (13080) on 2006年07月30日 2時45分 (#987192) ホームページ
          >エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。

          出回っていても2.0系が出てから結構立つんだし、まだ直していないのが問題なんじゃないの?
          と言うか、出回っていたって、メンテが終わった奴だろ。メンテが続けられているのならばとっくに直っているはず。
          俺は最近は見たこと無いな、日本語クッキーは。

          とほほのCookie入門でも
          >日本語を使用する際にはそれぞれ、%3B、%2C、%20のようにエンコードして記述しなくてはなりません。
          http://pzxa85.hp.infoseek.co.jp/www/wwwcook.htm
          と%エンコード必須みたいだぞ。
          ネットスケープのクッキーの仕様書はショボイので実際にはどうか知らんが、HTTPヘッダーにエンコード無しで日本語があること自体が変だろ。

          >#つか、Unix版でも、Apache2.0.xの初期の頃は化けてた気がするし、直したのならBugと認識したって事でしょう?#Win32だけ放置なのは、なんだかなぁ。RFC違反って事で、全プラットフォーム問答無用で化けて同じ動作なら、納得も行くんだがねぇ。

          メンテが終わったCGIを自分でメンテもしないで使い続けようとするのはセキュリティーのリスクも高いんじゃ?
          スプリクト言語のCGIでしょ?使い続けたいのならば自分で直せば良いんじゃ?
          多くの人が使い続けていると思っているのならばCGIの作者と話しつけて、貴方がメンテしていけば良いと思うけど.....

          ところで、クッキーの処理ってunixとwin32で動作変わるの?正確にはHTTPヘッダーの追加の動作だけど。
          io周りとか、OS固有の部分をwin32用に対応させているんじゃないの?

          で、ちょっとwin32でテストしてみた。
          ---------
          #! ruby -Ks
          STDOUT.binmode
          print "Content-type: text/html\r\n"
          print "Set-Cookie: 日本語だよ\r\n"
          print "\r\n"
          ---------
          の結果は
          >HTTP/1.1 200 OK
          >Date: Sat, 29 Jul 2006 16:57:01 GMT
          >Server: Apache/2.0.55
          >Set-Cookie: 日本語だよ
          >Content-Encoding: gzip
          >Content-Length: 20
          >Keep-Alive: timeout=1, max=100
          >Proxy-Connection: Keep-Alive
          >Connection: Keep-Alive
          >Content-Type: text/html; charset=shift_jis
          もう1回叩いたリクエストはこれ(GETとhostはの所は伏せ字にした)
          >GET http://********/test_cookie.rb HTTP/1.1
          >Accept: */*
          >Accept-Language: ja
          >Accept-Encoding: gzip, deflate
          >User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
          >Host: **********
          >Proxy-Connection: Keep-Alive
          >Pragma: no-cache
          >Cookie: 日本語だよ
          と、そのまんま出たぞ。

          >print "Set-Cookie: name=日本語だよ\r\n"
          に変えてみる。
          >Set-Cookie: name=日本語だよ

          >Cookie: 日本語だよ; name=日本語だよ
          が結果。「日本語だよ」もちゃんと残ったまま。
          化ける?化けないけど。
          >print "Set-Cookie: 日本語=文字化け\r\n"
          と変えてみた。
          >Set-Cookie: 日本語=文字化け

          >Cookie: 日本語だよ; name=日本語だよ; 日本語=文字化け
          とnameに日本語もOKじゃん(これはIEの実装の話だけど)。
          charsetを指定していないとかで、IEとかのブラウザが勘違いしているだけなんじゃ?
          httpd.confで「AddDefaultCharset shift_jis」みたく指定しとけば良いんじゃ?
          2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの?

          ふと思ったけど、日本語を正しく処理出来るかはブラウザにもよるんじゃ?ブラウザのバージョンにもよるし。
          古いバージョンのを使っている奴も入るだろうから、「全部直せ」どころか、もっと難しい「世界中の奴に日本語クッキー対応のブラウザ使わせろ」ってことか?日本中でも無理だろ。
          やっぱ、%エンコードするべきなんじゃ?
          安定性を考えるとそれがベストだと思うけど。アスキーコードを処理出来ないブラウザは無いだろうから。
          親コメント
          • Re:1.xのWin32 Binary (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2006年07月31日 1時08分 (#987588)
            >httpd.confで「AddDefaultCharset shift_jis」みたく指定しとけば良いんじゃ?
            何処からそう言う話が出て来たんでしょうか? 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とクライアントの責任だと思うので。
            親コメント
            • chanbaba さんが気にしていて、#987588 の Anonymous Coward さんが気にしていないのは、HTTP サーバとブラウザ間のプロトコルのレベルで Cookie の値が ASCII に制限されていないかどうか。

              仕様を読むと、手順を踏めば、RAW BINARY を流せるように見えます。

              1. Netscape 仕様 [netscape.com]ではエンコーディングを指定していませんが、定義が "This string is a sequence of characters ..." で始まっていてよく分かりません。形式的定義が無いんです。
              2. RFC 2109 (Netscape 仕様を RFC 化、Obsoluted by RFC 2965) [ietf.org] と RFC 2965 [ietf.org] では RFC 2616 [ietf.org] で定義された quoted-string が使えるので (quoted-string → qdtext → any TEXT except (") → any OCTET except CTLs, but including LWS とつながって) "~" の中なら CTL と '"' を除く OCTET を挿入してもよさそうです。(HTTP 1.1 の範疇で value を送信するのは、chanbaba さんも指摘するように、賢い判断だと思います)

              ただ、この話が #987588 の Anonymous Coward さんの望みどおりか、ちょっと心配です。私も Cookie の値に quoted-string なんて使ったことがありません。

              親コメント
            • by magicalchalk (27784) on 2006年07月31日 15時30分 (#987890)

              あ、本当にバグ報告済みでした。

              Bug 13029 - Win32 mod_cgi failure with non-ASCII characters in env var [apache.org]

              Win32 環境での環境変数を作成する際にコード変換が入っているようです。

              親コメント
            • >>httpd.confで「AddDefaultCharset shift_jis」みたく指定しとけば良いんじゃ?
              >何処からそう言う話が出て来たんでしょうか? 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ヘッダーは環境変数に入れる為に、複数行に別れている奴や同じ名前のヘッダーは加工して入れたりするのだろ?
              親コメント
          • IEのバグ

            #自分じゃ何も試してませんごめんなさい
        • by Anonymous Coward
          RFCなんかの仕様書で、定義されていない事が起こった場合の動作は、
          どうなるか予想出来ない、という定義で事である事が多いと思いますよ。

アレゲは一日にしてならず -- アレゲ見習い

処理中...