このエントリーをはてなブックマークに追加

こんにちは、ブログの順番が回ってくるのがあまりに早すぎると感じている山本です。

さて、今回のお題は「apacheのconfでも使わなそうな設定を使ってみよう」となりました。

なのであまり使われない、ディレクティブ、モジュール等を使っていきます。

尚、あまり使わないかどうかの基準については、私が使わないかどうかです。
一般的にどうかは気にしません。

mod_data

では始めに、「mod_data」を使ってみます。

mod_dataとはなにか？

公式のドキュメントには以下の説明がありました。

Convert response body into an RFC2397 data URL

つまり、レスポンスをRFC2397に変換してくれるとのことですね。

では、以下を追記します。

<Location /data/>
  SetOutputFilter DATA
</Location>

/data/ 以下に画像をアップロードします。

では、その画像を見てみましょう。

apache_001

おお。確かに、RFC2397形式になっていますね。

と、確かに変換されるのですが……
これどのように使うものなのでしょうか？

まず、htmlでimgタグを使用して画像を表示してみます。

apache_011

画像が表示されません。

次に、htmlソースを見ています。

<!DOCTYPE html>
<html>
<head>
<title></title>
<meta charset="utf-8">
<link rel="shortcut icon" href="">
</head>
<body>
test<img src="/data/test.jpg">
</body>
</html>

少し期待していたのですが、srcの中身が自動で変換されるわけでもないようです。

もし、自動でsrcを置き換えてくれるのでしたら、同時接続数を減らす等の負荷軽減に貢献してくれそうなのですが……。

これ、何の役に立つのでしょうか？

ForceType

「AddType」はよく使うのですが、「ForceType」というのもあるんですね。

すべてのマッチするファイルが指定の MIME コンテントタイプで 送られるようにする

とのことです。

DefaultType と違ってこのディレクティブはメディアタイプを決めることができるかもしれないファイルの拡張子も含め、すべての MIME タイプの関連付けを上書きすることに注意してください。

ともあり、メディアタイプを上書きするということですね。

<Location /force>
  ForceType image/gif
</Location>

を追記して

vi /force/test.txt
test

設置します。

apache_003

本来ならtestとだけ表示されるはずなのですが、画像と認識されています。

メディアタイプを追加ではなく、上書きする状況が浮かびませんが、覚えておくと何かに役立つのかもしれません。

LimitRequestFields

クライアントからの HTTP リクエストのヘッダフィールドの数を制限する

とのことです。

現在のリクエストのヘッダフィールドの数は6個あります。

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0

なので、5個に制限してみましょう。

LimitRequestFields 5

追記して、再起動します。

そして、リクエストします。

==> access_log <==
192.168.0.128 - - [07/Oct/2015:03:35:58 -0700] "GET / HTTP/1.1" 400 290 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0"

見事に弾かれました。

なぜこれの制限が必要なのか？という疑問があったのでちょっと調べました。

hashdos攻撃の対象になるようですね。

  • 参考

http://qiita.com/yuya_takeyama/items/7a717b334edd60bc6ce3
http://blog.tokumaru.org/2012/01/cookie-hashdos-attack-defense.html

この場合、LimitRequestFieldsだけではなく最大サイズの制限であるLimitRequestFieldSizeも調整を行う方が良さそうですね。

AccessFileName

分散設定ファイルの名前

分散設定ファイルとは何？と思ったのですが「.htaccess」のことなんですね。

別の設定ファイルを指定してみます。

AccessFileName .acl

vi /var/www/html/.acl
AuthType Basic
AuthName "Auth acl"
AuthUserFile /var/www/html/.htpasswd
require valid-user

「.acl」が読み込まれるかを確認します。

apache_006

Basic認証が表示されているところを見ると、.aclが読み込まれているようです。

さて、デフォルトの.htaccessはどうなっているのでしょうか？

.aclを削除して.htaccessを作成します。

vi /var/www/html/.htaccess
AuthType Basic
AuthName "Auth htaccess"
AuthUserFile /var/www/html/.htpasswd
require valid-user

そして、画面を表示してみましたが、Basic認証は求められませんでした。

AccessFileNameを使うとデフォルトの.htaccessは使えなくなるようなので、使用する際は注意が必要となりそうです。

因みに、.htaccessと.acl両方を読み込むように出来ないものかと以下の設定を試してみましたが、どうやら複数を指定した場合、先に書かれたもののみ有効になるようです。

AccessFileName .htaccess .acl

DirectorySlash

パス末尾のスラッシュでリダイレクトするかどうかのオンオフをトグルさせる

http://localhost/data にリクエストがあった場合に、dataディレクトリがあれば http://localhost/data/ へリダイレクトされるということですね。

確かに、いつも末尾のスラッシュなしでディレクトリをリクエストした場合、末尾にスラッシュが自動で付与されていましたが、当たり前過ぎて、意識したことがなかったです。

いつものごとく追記します。

DirectorySlash Off

そして、http://192.168.0.193/data をリクエストします。

apache_007

確かに、スラッシュが付与されなくなっていますが……、意図的にスラッシュを外したいといった状況に遭遇したことがないので、今ひとつ使いどころが分かりません。

mod_speling

リクエストの綴りが間違っていたり、大文字小文字が違っていたりするために、Apacheのコアサーバがドキュメントへのリクエストへの応答を正しく提供できないことがあります。
このモジュールは、他のすべてのモジュールがあきらめた後であったとしても、リクエストに合うドキュメントを見つけようとすることによりこの問題の解決を試みます。このモジュールはリクエストされたディレクトリにあるそれぞれのドキュメントの名前と、リクエストされたドキュメントの名前とを大文字小文字の区別を無視し、一文字までの綴りの間違い(文字の挿入/省略/隣合う文字の置換、間違った文字)を許可して比較することにより、目的を達成しようとします。
この方法でリクエストに合うドキュメントの一覧が作成されます。

URLの間違いを多少は吸収してくれるということですかね。

CheckSpelling On

追記して、確認すると

[Thu Oct 08 20:05:24.969899 2015] [core:alert] [pid 4701] [client 192.168.0.128:55418] /var/www/html/.htaccess: Invalid command 'CheckSpelling', perhaps misspelled or defined by a module not included in the server configuration

読み込まれていませんよと。

[root@localhost modules]# ll /etc/httpd/modules/mod_speling.so
-rwxr-xr-x. 1 root root 15256 Aug 24 11:12 /etc/httpd/modules/mod_speling.so

ただモジュールは既に用意されているようなので、includeします。

大文字でディレクトリを作成して

mkdir /var/www/html/UPPER

http://192.168.0.193/upper をリクエストします。

apache_008

URLが大文字に変換されました。

では次に、リクエストしたドキュメントが見つからない場合、リダイレクト応答するそうなので試してみます。

vi /var/www/html/UPPER/index001.html
001

http://192.168.0.193/UPPER/index002.html をリクエストします。

apache_009

index001.html にリダイレクトされました。

続けて、「よく似たドキュメントが複数見つかった場合、そのリストがクライアントに返され、クライアントが正しい候補を選択できるようにします。」
と仰っているので

vi /var/www/html/UPPER/index003.html
003

を用意して、http://192.168.0.193/UPPER/index002.html をリクエストします。

apache_010

選択肢が出来ました。
というか、300のレスポンスコードを初めて見ました。

さて、このモジュールですが、1.1から存在するようです。

どんな需要があるのか分かりませんが……、歴史的事情によりってやつなんですかね。

あとがき

色々と試してみましたが、普段使用することがないだけあって、使いどころがよくわからないものが多かった印象です。

ドキュメントを見ても、日本語訳が無いのは良いのですが、英語版を見ても説明が少なく、何が出来るのか今ひとつ分からなかったりと、まとめるのに苦労させられました。

その中でも、mod_spelingとmod_dataの存在には驚かされました。

特に、mod_dataは調べた限りでも、有効な使い方をしている情報は見つかりませんし、何のためにあるのかとても疑問です。

もし、有意な使い方をご存知の方がおりましたら、是非とも教えて頂きたいです。

このエントリーをはてなブックマークに追加

こんな記事も読まれています：

  1. 無料で使えるSSL証明 Let’s Encrypt を試してみよう!