Googleが開発?したhttps向け高速転送プロトコル「SPDY」。その存在は知ってたけどふとApacheの対応状況はどうなのと思って調べたところ、まだベータ版ながらもGoogleから「mod_spdy」が出ている事を確認。(更にApache Foundationに寄贈されたとの話なようなのでいずれ標準化も見込める)

 試しにインストール。ほぼそれで完了な簡単なお仕事。

 でもタイトル通り。これまでSSL限定にすべく「SSLRequireSSL」を設定していた箇所で403のPermission Errorが発生するようになってしまった。解決策らしきものは見つからなかったので取り急ぎ上記設定を解除。

 まあGoogleさんからすれば「世の中全てhttpsで」が主張なので特定箇所だけSSLを強制するこのディレクティブが無意味なのはわからないでもない。

関連タグ:GoogleApacheSSL
2014-12-03 [技術・作業]


関連タグ:ApacheSSL
2014-04-08 [セキュリティ]

 以前、表示上は特に問題ないのにGoogleのサイト解析でやけに404エラーが発生した場合の話を書きました。
 これはApacheでRewrite設定をしてる際に「/」(スラッシュ)をURLエンコードして出来る「%2F」がURLに混じってると404エラーになる、でもZendFrameworkだと表面上は問題なく表示されるので分かりづらい、という話でした。
 対策としてhttpd.confに「AllowEncodedSlashes On」を入れて終了。
 先日サイトを自宅サーバからVPSサーバに引っ越した際にも同設定を書き込んで(※引越し時に何の設定だか忘れてて軽く悩みましたが)終了…のハズでした。

 ところがサイト移転から数週間。Googleのサイト解析曰く「404エラーが増えてきたよ」。
 最初は移転以降のゴタゴタかなぁと思ってあまり真剣にとらえてなかったけど、状況は時系列と共に悪化。一定割合で増えている。というかsitemap.xmlに従うクロールの増加とともに増えている感じ。試しに自分でエラーの出てるURLにアクセスして(※閲覧は普通にできて)すぐログを確認すると確かに404エラーが発生している。ついでにログをgrepかけると結構な数の404エラーが発生している。このタイミングでようやく上記「AllowEncodedSlashes」の存在を思い出したが、やはり上述の通り既に設定は完了している。

 うーん、とりあえず「AllowEncodedSlashes」について本家Apacheサイトに調べにいったところ、

 
 コンテキスト:    サーバ設定ファイル, バーチャルホスト

 
 …なるほど。
 実はVPSサーバ導入と同時によーやくオリジナルなドメインを取得したのでDNSも自前で運用することに。その際ついで、というか後々の拡張性を考えて公開用ホストFQDNをネームベースのVirtualHostに変更したのでした。
 てなわけで該当する<VirtualHost>内にも「AllowEncodedSlashes On」を記述。Apache再起動。…無事404エラーが出なくなったのでした。

 まー当たり前と言えば当たり前な話だったのかもしれないですが、こーゆー設定は全設定で共有してくれても良いと思うんですけどねぇ。否定したい時だけOffと明示すれば良いだろうし。
2013-05-27 [日記]

 ふとGoogle Analyticsで本サイトの状況を確認してみると、やけにページが見つからない場合の404エラーが多発していることに気づいた。
 が、しかしである。そもそもZend Frameworkを使用するためにRewrite設定でほとんどのリクエストをindex.phpにリダイレクトかけてるので404エラーの発生率はほとんどないハズ(無いわけではない)。
 と思ってアクセスできないページとやらにアクセスしてみると普通に表示される。なんだろう、一時的なものかなー、と思いGoogleのツールで再取得させてみると「取得できません」。あれー?
 次にブラウザのプラグインでHTTPヘッダをとれるヤツを起動、問題のページにアクセスしてみると、ページは表示されるのだがレスポンスは404エラーが出てRUUUUUUUUUUU!!

 なんだこら、404出てるのに表示されるってなどーゆー了見だ、ととりあえず問題のURLを漁ってみると、URL内で「/」をURLエンコードした「%2F」が入ってると404エラーが発生してることが判明。そこから更に調査して、Apacheの場合URLにこのエンコードしたスラッシュが入っているとデフォルトだと404エラーを返す事も判明。それを抑止するためにhttpd.conf等にて「AllowEncodedSlashes on」を設定すれば良いことも判明。設定→再起動→確認。無事404エラーの抑止に成功しましたとさ。

 解析ツールのログ、グラフを見てみると今年の1/20頃から急にエラー扱いのページが増えている。別にこの頃から「%2F」を使いだしたわけでもないし、Apacheの設定を変えたりしたわけでもない。ひょっとするとGoogleの解析方法が若干変わったということだろうか。色々あるもんですなぁ。ちゃんとチェックしておかないと。
2012-03-28 [技術]

 前ページのApacheリビルド話ですが、そもそもの起点は少し前に挫折したWebDAVを 使いたいなあ、という事でした。いやフツーに使う分には問題ないんだけど、 どうも2GBを越えるサイズのファイルを送ろうとするとエラーが起きて止まってしまう。
 ログを見ると「Content-Lengthが変だよ」的な内容。色々調べてみたところ、 よーするにContent-Lengthを扱う変数の型「apr_off_t」の大本が32bitのintなので 2147483647byteを越えるサイズに対応できない、という事だった。WebDAVの問題とゆーより Apacheの問題とゆーよりアーキテクチャの問題なのか(苦笑)。
 この手の情報はあんまり見つからなかったものの、一応対応パッチやら 対応コンパイル方法やらは見つかったので試したのだが、どーもイマイチうまくいかない。 ソースに直接手を出して、関係しそうな所の変数の型を「long long」に書き換えたりして とりあえず最初のContent-Lengthで止まる所は突破したんだけど、実際にファイルを送る際に 途中で「ファイルでか過ぎ」で止まってしまった。

 あんま細かいところまで手を出してるヒマと時間が無い。よーするに64bitCPUと 対応OS、及びその環境で作成したApacheがあれば良いわけだ。
 幸いにもウチのマシンはOpteron機。つーかこないだ間違いで作った(笑)Athlon64 FX-51機が 手つかずで残ってる。コイツに64bit版Fedora Core4をインストール。DAV設定。 テスト。・・・・・・無事転送成功。本当の意味で64bitの恩恵に預かったのはコレが初めてだ(苦笑)。 あ、ただしコレはクライアント側はマイネットワークからネットワークプレイスの追加で DAVフォルダを認識させた場合の話。WebDAVへの接続用としてNetDriveがインストールされてるんだけど、 これだと1.8GBくらいのところでエラーになってるっぽい。特にそれっぽい設定ないけどなあ。
 まあ、何にせよこれで対応容量的には実用に耐えうるWebDAVができた。 後は日本語環境の問題だが・・・コレはまだイマイチかねえ(苦笑)。

 あ、あと話は戻るけど前ページhttpd.confのinclude話は、どーやら64bit対応コンパイル (コンパイル時にオプションLARGEFILE_SOURCEとFILE_OFFSET_BITS=64をつける) をした場合にPHPをそのままにしてると起きるっぽい。*.confでまとめてincludeしようと したときに、どーやらPHPのところで止まってたっぽい。個別にincludeした場合でも php.confを取り込んでると、アクセスした時に子プロセスがセグメントエラーで 落ちてしまう。まあ試してないけど、PHPも同様のオプションつけて リビルドすれば問題ないのでしょう。
関連タグ:Apache64bitOS
2005-10-27 [技術・作業]

 Fedora Core4デフォルトApacheのとある設定を変えるべくrpmのリビルドを行った。 リビルド→インストールは滞りなく終わったのだが、いざ起動する際に「”SSLRequreSSL”っての ミススペルじゃない?」とかゆーエラーが出て失敗してしまった。
 どうやらmod_sslが上手く読み込まれていないっぽい。mod_sslのリビルドに 失敗したかと思ったが、httpd.confに直接LoadModulesを記述する限りでは 問題なく読み込まれてるっぽい。つかよくよく確認したところ、/etc/httpd/conf.d配下にある *.confの類がことごとく読み込まれてないっぽいことが分かった。つまりmod_sslを読み込むところの ssl.confがシカトされていた、と。
httpd.confのInclude項目は以前と特に変わらず

Include conf.d/*.conf


てなカンジで*.confモノを全て取り込むようになっていたので、ためしに

Include conf.d/ssl.conf


と言う風に読み込むファイルを指定したところ、今度はちゃんと読まれた。 同じように他のconfファイルも逐一指定したらどれもちゃんと読まれた。 どこかのタイミングでワイルドカード使えないようになったのだろうか。 イマイチ考えづらいのだが・・・。ま、パフォーマンスやらセキュリティやらの観点で見れば 動作させるモジュールに制限を加えるのは正しい事ではあるけど。
関連タグ:Apache
2005-10-20 [技術・作業]

1.oci8対応のPHPで、時々Oracleにアクセス出来なくなる。Apacheの再起動で直るけど。

2.同じくoci8対応のPHPで、コマンドラインからシェル起動させてoci8関数を使うとシェル終了時に必ず セグメント違反が発生する。終了したタイミングなんでデータの処理は一見問題ないのだが・・・。

3.Redhat-EL-AS-v3標準OpenLDAPのSRPMのconfigureオプションに--enable-phoneticつけてもphoneticが 有効にならない。
関連タグ:LinuxApacheOracle
2005-02-02 [技術・作業]