Apache更新に伴う.htaccessの修正†
- ページ: BugTrack
- 投稿者: Ratbeta
- 優先順位: 普通
- 状態: 完了
- カテゴリー: 本体バグ
- 投稿日: 2004-10-24 (日) 16:37:20
- バージョン: 1.4.4
メッセージ†
Apacheの更新に伴って、1.4.4に含まれている.htaccessの正規表現が使えなくなっています。
.htaccessを修正する以外に、orgサイトでの告知も必要かと思われます。
- 配布されている.htaccessをそのままUPするとまずいようです。index.phpと同じ階層で"?i:"と書かれている部分を取り除けばイイっぽいですが…今日サイトが見れなくなって、サポート連絡したらそのように修正して下さってたので… -- Kevin
- ふむふむ。Apacheの更新をされたのはどなたで、何から何へですか? -- henoheno
- .htaccessが使えなくなってるのは例えばXREAなどです。Apacheの1.0系、2.0系共通で、バージョンはそれぞれ1.3.31から1.0.32、2.0.50から2.0.51の間での変更です。 -- Ratbeta
- 私の調べた結果をBugTrack/652の一番後ろに書いてあります(やっぱり完了したペイジに書くのは良くなかったか....)。 -- よっちい
- Ratbetaさんよっちいさんありがとうございます。よっちいさんの情報は数日前に目を通した気がするのですが、探せませんでした (^^; Apacheの都合の様ですが、事情が良くわかりませんから、ちょっと apache.org を見てこないといけませんかね -- henoheno
http://www.apache.org/dist/httpd/CHANGES_1.3
Changes with Apache 1.3.32
*) Fix a bunch of cases where the return code of the regex compiler
was not checked properly. This affects mod_usertrack and
core. PR 28218. [André Malo]
http://www.apache.org/dist/httpd/CHANGES_2.0
Changes with Apache 2.0.50
*) Fix a bunch of cases where the return code of the regex compiler
was not checked properly. This affects: mod_setenvif, mod_usertrack,
mod_proxy, mod_proxy_ftp and core. PR 28218. [André Malo]
- Bugzilla Bug 28218: errors in regular expressions for LocationMatch cause silent failures
- この件で合っていますか? > Ratbeta -- henoheno
- 手元のFreeBSDではapache-2.0.52_1でこの.htaccessが動いているから、違うかな・・・ -- henoheno
- 手元で再現しているという方は、環境を教えて下さい。(Fedora Core2 etc) -- henoheno
- FreeBSD/i386 4.10-RELEASEにソースからコンパイル&インストールしました。 -- よっちい
- (手元の環境ではないけれど)XREAサーバはRedHatLinux 7.3で、Apacheは1.3.32のようです。もしかして1.x系だけ? -- Ratbeta
- 出来れば各ディレクトリの.htaccessもDirectoryMatchを使ってルートの.htaccessに集約できればいいのかもしれませんが…。 -- Ratbeta
- セキュリティホールmemoによれば、1.3.32が正式リリースでない説あり。 http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2004/10.html#20041023_apache -- henoheno
- Ratbetaさん、25日の時点でバージョンを明確に指摘できたのは何故か、それと上にあげたBugzillaのバグのものとそれが一致するかどうかを教えて下さい。 -- henoheno
- 25日->24日ですよね?それなら、XREAとApacheの更新のタイミングがほぼ同じであった事、CHANGESから確認した事、(その後に)XREAサーバinfoでの確認などからバージョンを特定しました。で、Bugzillaのバグですが、(断定は出来ませんが)これと同じ物だと思われます。 -- Ratbeta
- 某BBSのログを見てたらApacheのバグのような気もしてきました…。仮にApache側の問題だったとしてそれもPukiWiki側で対策するべきなんだろうか…? -- Ratbeta
- お疲れ様です。コメントありがとうございます :) (Apacheに限らず)関連プロダクトの問題に気づいたときは、どうにかしてその改善を図る(知らせるetc)のがマナーと考えています。現状のPukiWikiについては、既に状況と対処法が明らかになっていますから何も心配していません。 -- henoheno
- (正式リリースとなる)Apache 1.3.33がリリースされましたが、これではこの問題は修正されているのでしょうか?当方にはApache2しかないもので… (^^; -- Ratbeta
- 1.3.33でもNGでした。なので正規表現の扱いが変わったのは意図的なものではないかと思います。 -- よっちい
- 確認&お知らせいただきありがとうございます>よっちい しかし、それは現在もそうであるというだけで、意図しているとまでは断定できませんね (^^; -- henoheno
- まとまった時間を取って、調べてみました。まず1.3.31と1.3.32の間での変更点としてap_pregcomp()の戻り値を見るようになっていました。
- r = ap_pregcomp(cmd->pool, cmd->path, REG_EXTENDED|USE_ICASE);
+ r = ap_pregcomp(cmd->pool, cmd->path, REG_EXTENDED|USE_ICASE);
+ if (!r) {
+ return "Regex could not be compiled";
+ }
なので、この変更は妥当な感じがします。さらにもうちょっと調べてみると、apache1とapache2でap_pregcomp()からコールするregcomp()の実体が異なるようです*1。
apache1 | OSの(libcの)regcomp() |
apache2 | srclib/pcre/pcreposix.cのregcomp() |
ですから、1.3.32以降の動作はOS(libc)の実装依存になると思われます。が、良くみてみるとUSE_ICASE(= REG_ICASE)を付加しているので
REG_ICASE Compile for matching that ignores upper/lower case distinc-
tions. See re_format(7).
ということ(FreeBSD/i386 4.10-RELEASEのregex(3)より)で.htaccessでの?i:指定はそもそも不要ではないでしょうか。 -- よっちい
- 情報ありがとうございます。その変更は http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_core.c (1.337) みたいです。やはりきっかけは上記のBugzilla Bug 28218ですね。 -- henoheno
- そしてこのファイルの上部にはこのようなdefineがあります。 -- henoheno
/* We use this in <DirectoryMatch> and <FilesMatch>, to ensure that
* people don't get bitten by wrong-cased regex matches
*/
#ifdef WIN32
#define USE_ICASE REG_ICASE
#else
#define USE_ICASE 0
#endif