Request Entity Too Largeエラーが出る。原因はLimitRequestBodyだった

ウェブアプリで2MBのファイルをPOSTでアップロードする処理をしたら、

HTTP 413
Request Entity Too Large

The requested resource
/test.php
does not allow request data with POST requests, or the amount of data
provided in the request exceeds the capacity limit.

というエラーが。
「Request Entity Too Large」でググるとnginx関係のエラーが出てきますが、ウチのサーバーはnginxなんて入れてないので、おかしいな～と思ってました。

で、httpdのエラーログを確認すると、

Requested content-length of 2073274 is larger than the configured limit of 1024000

と出てました。
なんか制限かけてるようです。

とりあえずhttpd.confで「1024000」を検索かけてみたところ、

LimitRequestBody 1024000

という記述が。明らかにこれが怪しいです。

ゼロをひとつ増やしてhttpdを再起動したら、エラーが出なくなりました。

なんの目的でLimitRequestBodyを設定したのか記憶にないのですが、テスト環境なんで消し忘れとかだと思います。

cssのopacityプロパティは子要素まで透過してしまう

背景を透過する必要があって、いつものようにopacityで対応できると思ってたんですが、実際にやってみると、opacityはその子要素までも透過してしまうという仕様になっていることがわかり、困ってしまいました。

で、ググってみたところ、rbgaというのを使えばこの問題を回避できることがわかりました。

http://d.hatena.ne.jp/Hamachiya2/20120506/opacity_rgba

勉強になりました。

ファーストサーバーのデータ消失事故

が、世間を騒がせています。

「お客様の万一のデータ紛失に備え、1日1回自動でバックアップを実施しています。」

と謳って料金を徴収しておきながらデータ全消失、しかも人災が原因というから救いようがないです。

さらにソフトバンクの株主総会が終わるまで情報統制がかかっていたなど、かなりきな臭いニオイもしています。

というわけで今回の教訓は、

・万が一への備え(バックアップ)は絶対に必要

・ソフトバンクグループ、マスコミは信用出来ない

という感じでしょうか。

何か事故が起こっても、１～２日くらいで別サービスでサーバー立ててサービス再開できる、というくらいの備えを用意したいですね。

Googleウェブマスターツールでクロール頻度が変更できない

ウェブマスターツールでGoogleBotのクロール頻度を設定する項目があるのですが、

「このサイトには、特別なクロール速度が設定されています。このクロール速度を変更することはできません。」

という表示が出るケースがありました。

ググってみても、これといった情報は出てきません。

そこで表示言語を英語にしたところ、

「Your site has been assigned special crawl rate settings. You will not be able to change the crawl rate.」

というメッセージになったので、こっちでググってみたところ何件かめぼしい情報がヒット。

http://www.seroundtable.com/google-crawl-cdn-14126.html

「ホストがCDNに乗ってる場合、Googleが勝手にクロール頻度を最適化するので、ユーザー側でクロール頻度をいじれないようになっている」ということのようです。


http://stackoverflow.com/questions/9265790/how-can-i-change-googles-crawl-rate

こちらは「サーバーをEC2(AWS)に変えたらクロール頻度を調整できなくなって困ってる」という投稿。


http://forums.digitalpoint.com/showthread.php?t=1527405

こっちは少し古いですが「みんな同じだよ。気にスンナ」みたいなスレッド。


そんなわけで、Googleが正式にアナウンスしてるわけではありませんが、「サイトがCDNやEC2(AWS)に乗っているサイトはクロール頻度の調整ができない」ということらしいです。

phpの「Notice: Undefined index」を非表示にする

古いphpアプリの環境を移したとたん、「Notice: Undefined index」というNoticeメッセージが出るようになりました。

「error_reporting(E_ERROR)」とかにすれば非表示にできるのですが、全スクリプトにこの記述が必要になります。かなりめんどくさいです。

というわけでphp.iniのほうに「error_reporting = E_ERROR」を書いてhttpdをrestart。

これで解決しました。

phpのstrtotime関数を使って文字列を日付型に整形する

よく忘れるのでメモ。

echo date("Y/m/d",strtotime("20120418"));

こんなのもいけちゃいます。

echo date("Y-m-d",strtotime("Sat, 14 Apr 2012 13:17:36 +0000"));

php.iniのmax_input_varsというパラメータ

php5.3以降で、新たにmax_input_varsというパラメータが追加されていました。
これはgetやpostで受け付けるパラメータ数の上限をあらかじめphp.iniの設定で決めておくというもので、DOS攻撃の対策として追加されたようです。

デフォルト値は1000。

普通1000件ものパラメータを受けるようなWebアプリはないと思います。また今はAjax全盛時代なので、一回のリクエストのパラメータは少なくなってきていると思います。

なんですが、たとえば古いWebアプリとか、条件が重なったりするとこの制限にひっかかることがあると思います。というか自分がひっかかりました。

そういう場合はアプリ側を作りなおすのが最善だと思いますが、一時しのぎとしてこのmax_input_varsの数字を増やしておけば対処できます。

参考
http://d.hatena.ne.jp/gallu/20120111/p1