にしし らぼらとりー

ああ、ダメかも知らんな……。details要素とsummary要素で作る折り畳み機能だと、span要素とかの内側には文法的に書けないので、安易に実装してしまうと本文中の装飾が崩れることになる。

• details要素の親要素になれるのは「フローコンテンツを受け入れる要素」だが、
• span要素の内側に書ける要素は「記述コンテンツ」のみ。

昔の言い方で言うところの「インライン要素の中にブロックレベル要素は書けない」という話だが。
まあ、自由装飾機能みたいに、デフォルトでは非表示にしておいて、「分かっている人だけONにしてくれ」という形態で実装しておく方法でも良いかもしれないけども。ただ、既に隠せる装飾機能が存在することを考えると、あえて（よく分かっていない状態で使うと他のデザインが崩れる可能性のある）機能を加える必要性もなさそうな気もする。

やはり、「表示できる投稿が1件も見つかりませんでした。」とか「指定された番号の投稿は存在しません。」とか、表示できる内容がなかった場合には、HTTPステータスコードでも404を返すようにした方が良いんだろうな。（今は全部200）

悪質なBot対策とか、攻撃を試そうとする不正アクセス対策とかで、何らかのエラーメッセージを返すときには、単にメッセージを表示するだけではなくて、200以外のHTTPステータスコードも返す。これは単にエラーページがキャッシュされたりしないように、という理由だけではなくて、Webサーバのアクセスログにエラーの発生事実が残るからでもある。HTTPステータスコードはログに記録されるので。自前でエラー発生の履歴を残そうとすると無駄な処理が増えてしまうが、Webサーバのアクセスログならどうせ問答無用で記録されるので、それに頼るのが最も消費リソースが少なくて済む。ただ、何でもかんでも 403 Forbidden とかを返してしまうと、「どの対策に引っかかったアクセスなのか？」が判別できない。Webサーバのログに記録されるのは、本当にHTTPステータスコードの番号だけでしかないから。そこで、対策内容によって「400 Bad Request」とか「429 Too Many Requests」とか、使えそうなHTTPステータスコードを使い分ける。……のだが、それでも足りなさそうな場合に、もっと何か使えそうなHTTPステータスコードはないか……と探すことになる。そこでふと思い出したのが、エイプリルフールジョークから作られた「418 I'm a teapot」。これは無害そうなので、識別のために使っても問題なさそうな気がする。……と思ってMDNの418 I'm a teapotページを見てみたら、一部のウェブサイトでは、自動化されたクエリなど、処理したくないリクエストに対してこのレスポンスを使用しています。と書いてあってちょっと笑った。みんな、考えることは同じなのか。

以下の3記法を新設した。（全部、[設定]→[補助出力]で設定できる値を表示する機能。「状況に応じた見出し」の出力用途くらいにしか使っていなかった。）

• [[GALLERY:NAME]] :ギャラリーモードの名称を挿入
• [[PICTS:NAME]] :画像一覧モードの名称を挿入
• [[SITEMAP:NAME]] :サイトマップページモードの名称を挿入

要望を頂いて、そういえばその記法はなかったな、と気付いた。需要があるとは思っていなかった、というのもあるけども。広く需要があるのかどうかが分からないので、まあ検討リストに入れようかな、と一瞬思ったのだが、そもそも処理が極めて簡単だったので、何も考えずに実装した。

てがろぐ「画像の管理」画面から、画像ファイルのタイムスタンプを変更できる機能の実装ができた。この機能を使って画像ファイルのタイムスタンプを修正することによって、間接的に画像の並び順（＝画像一覧モードでの並び順や、新着投稿画像の並び順や、画像管理画面での並び順）を変更できる。

今日は、てがろぐの開発をずいぶん進んだ。ただ、あまり表には見えない部分の実装だけども。いろんなURLに対して短期間に絨毯爆撃してくるBotがサーバ負荷を高めてしまう問題に対処するには、やはりサーバ側の機能に頼るのでは不足なので、てがろぐ自体に『同一IPアドレスからxx秒間にxx回以上の頻度でアクセスがあったら一定時間ほど「429 Too Many Requests」エラーを返す』という負荷軽減機能を用意した。
負荷軽減策なので、極力何も処理しないうち（データファイルを読み込むよりも前なのはもちろん、設定ファイルすら読み込まないうち）にアクセス制限を施す必要があるので、tegalog.cgi と同じ位置に blackcheck.ini という設定ファイルを置いた場合にだけ実行されるようにした。（※管理画面から設定できるようにすると、「設定ファイルを読み込んだ後」のタイミングでしか実行できない問題があるので。）
このファイルに例えば、

• Duration=60
• LimitFreq=10

というような記述があれば、『同一IPアドレスから60秒間に10回を超えるアクセスがあったら、次の60秒間は「429 Too Many Requests」エラーだけを返す』というような制限になる。
あくまでも「様々なURLに対して絨毯爆撃してくるBot」（≒毎秒数件みたいな超人頻度でアクセスしてくるBot）への対策が目的なので、「何の表示条件も限定されていないページ」に対しては無制限に閲覧を許可するし、RSSの閲覧も無制限に許可する仕様になっている。もちろん、管理画面へのアクセスも制限の対象外である。それ以外の「サブコンテンツ」のURLに対してだけ、アクセス頻度をチェックして制限を掛ける。要るかどうか分からないが、一応はホワイトリスト的に任意のIPアドレスを制限から除外できる仕様も用意はした。
この機能でしばらく運用してみて、サーバ負荷の高まり(の防御具合)を確認してみるとする。

絨毯爆撃してくるBotによる負荷を軽減させるには、やはり「同一IPアドレスから30秒間に2回以上の頻度でアクセスがあったら一定時間ほど429を返す」みたいな処理が必要か……？