エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント3件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
mod_proxyを経由するとURIが勝手にデコードされる - 脱線こそ本道
フロントに Apache を置き、バックエンドの Tomcat に mod_proxy_ajp 経由でリクエストを転送するという... フロントに Apache を置き、バックエンドの Tomcat に mod_proxy_ajp 経由でリクエストを転送するという一般的な構成において、日本語では探しても余り見つからなかったネタがありましたので書いておきます。 リクエストURIに「URLエンコードされた文字」を含む場合、mod_proxy はこれらの文字をデコードした上で、バックエンドに転送します。 この動作は、通常のWebアプリでは特に問題にはならないと思います。 しかし、次のようなリクエストURIを考えてみましょう。 /path/to/foo%3Bbar これをデコードすると次のようになります。 /path/to/foo;bar ご承知の通り、URIにセミコロンが含まれていた場合、Tomcat はそれ以降の文字を別セグメントと認識してしまいます。このため、mod_proxy_ajp 経由の Tomcat では、 requ
2012/10/03 リンク