日曜研究室 LLVMによるプログラミング言語の実装 xv6ソースコードリーディング 技術 日記
日曜研究室

日曜研究室

まだ庭の小石の数を数え終わっていない

技術

URLエンコードの現実

投稿日
2010/10/24 日曜日
カテゴリー
技術
タグ
著者
Take it easy!

URLエンコードってURLにどんな文字でも埋め込めるようにするもの、と今までは大雑把にはそう思ってたんですが、概念上は正しくても、現実的にはURLエンコードしておけば万事OKという訳ではなさそうです。

例えば、Apache 2.0.46 以降にはAllowEncodedSlashesという「パス分離文字 (/ は %2F、さらにシステムによっては \ に対応する %5C) が存在する URL の使用を 許可するかどうかを決定する」設定項目があり、設定内容によってはURLエンコードしたといえスラッシュやバックスラッシュは含めない方がよさそうです。
AllowEncodedSlashesはデフォルトでoffなので、URLエンコードしたスラッシュが使えない環境の方が多いかと思われます。

また、GooglebotはURLエンコードしてても%2Fだけはスラッシュに戻してアクセスしてくるようで、大抵の場合変なところでパスが区切られてしまうので404等になってしまいます。
（?以降のパラメーターについては、URL等をパラメーター化できなくなるのでそんなことはしないと思われますが、調べてないのでわかりません。）

アクセス後アドレス欄の表示をURLデコードした値にするブラウザ（ほとんどのブラウザがそうだと思います）では、%2Fが含まれてるURLにアクセスは出来ますが、アクセス後アドレス入力欄では表示が%2F→スラッシュとなってしまいますので、そのURLを再利用（そのままエンターでもう一度アクセスするとか、他のブラウザ等にコピペするとか）するとやはり同じような問題が発生します。

他にもNaverのbotであるYeti/1.0は、シャープ記号（正確には番号記号）をURLエンコードした%23という文字がURLに含まれるとそれ以降の文字を切り取ってアクセスしてくるようです。
こちらも大抵の場合変なところでパスが切り取られてしまうため404等になってしまいます。
（こちらも?以降のパラメーターについては、前述と同じ理由でそんなことはしないと思われますが、調べてないのでわかりません。）

他にもBot毎やブラウザ毎に挙動の違いがたくさんあるかもしれません。

Webサーバーのログを数行みただけでろくに裏も取らずに書いてますので、間違いの指摘や補足は大歓迎です。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です



※画像をクリックして別の画像を表示

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。