WordPress に Authorization ヘッダが無いと言われたので

WordPress を 5.6 にしてみたところ、サイトヘルスの項目に Authorization ヘッダが無いとのメッセージが出ていた。

とりあえずこのヘッダが無くても、私の使用環境では問題無さ気な感じではあるのだが、API 経由で投稿する場合などに必要みたいで、Apache の場合だと、以下のように .htaccess に記載すれば良さそう。

<IfModule mod_rewrite.c>
	RewriteEngine On
	# RewriteCond %{HTTP:Authorization} . # 追記参照
	RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>

・追記
上記で「RewriteCond %{HTTP:Authorization} .」を設定すると環境変数 Authorization になにも入っていないときはヘッダがセットされないため、WordPress のサイトヘルスでは引き続きヘッダが無いメッセージが出るようです。「WordPressでREST APIを利用して自動投稿を行う | 一郎くんどっとこむ」で公開されているようにこの部分を削除無いしはコメント化すると問題が解決しました。(追記終わり)

しかし何で、改めて Authorization ヘッダの値を取得して Authorization ヘッダにセットするという謎なことを行わないといけないのだろう。PHP-FPM だから?

でも設定ファイルにはヘッダを渡すように「SetEnvIfNoCase ^Authorization$ “(.+)” HTTP_AUTHORIZATION=$1」って入っているしなぁ。

・参考
Authorization ヘッダが取得できない環境への対応 · Issue #1607 · EC-CUBE/ec-cube · GitHub

・追記
うーむ、なぜかまたヘッダが無いと表示が出た。手動で .htaccess を編集して保存すると表示されなくなる。まるで .htaccess がキャッシュされているかのよう。謎だ。

・更に追記
Apache 2.4.13 以降では、「CGIPassAuth」というディレクティヴがあるので、こちらで試しています。
参考: http – Apache 2.4 + PHP-FPM and Authorization headers – Stack Overflow

WordPress で WPSuper Cache + WPTouch を併用する場合

WordPress で WPSuper CacheWPTouch を併用する場合ですが、何も難しく考えることはなく、以下のようにすれば良いことがわかったので覚え書きです。

■基本的な方法

  • WPSuper Cache と WPTouch をインストールする。
  • WPSuper Cache の設定を下記の状態に変更し、「ステータスを更新」とする。
    • 「詳細」タブにおいて、以下にチェックを入れる。
      • ヒットしたページをキャッシュし、素早くアクセスさせる。 (推奨)
      • キャッシュファイルの提供に mod_rewrite を利用する。 (推奨)
      • Mobile device support. (External plugin or theme required. See the FAQ for further details.)
  • 「プラグイン」タブに移動し、WPTouch を「有効」とする。
  • 再度「詳細」タブに移動し、「Mod_Rewrite ルールを更新」のボタンをクリックする。

以上で終わりです。

■注意事項

上記は、mod_rewrite を使用している場合の設定であることと、WordPress インストールディレクトリの .htaccess ファイルに対してウェブサーバのプロセスから書き込みが可能であることが必要です。

■何故いまさらこんな記事を書いたのか

Safari の「開発」メニューでは、iPhone の Mobile Safari のユーザーエージェントを設定でき、これで動作を確認できますが、一旦モバイルページを表示した後、ユーザーエージェントをデフォルトに戻しても、引き続きモバイルページが表示されるという現象が発生していて、何故なのか、悩んだんですよねぇ。

しかし、一度モバイルページがキャッシュされたページを、表示テストに利用した Safari 意外のデスクトップブラウザで表示すると、PC 用のページが正常に表示される挙動から推測するに、WPTouch プラグイン側で、このブラウザはモバイル表示 ON という記憶をしているように思われます。

と言うわけで、こう言うエントリを書いてみました。

WordPress 構築サイトの負荷軽減について

自サーバを何故か suEXEC と suPHP で構築してしまい、WordPress 構築サイトの過負荷で苦しんだのを何とかした際のメモ。

  • WP Super Cache を使う

    WordPress 側での対策として、「WP Super Cache」を mod_rewrite かつ、プリロードを有効として使用する。これだけでもだいぶん違う。

  • サイトへの過剰な接続を抑制する

    WP Super Cache は素晴らしく、これでおおよそ大丈夫なのだが、それでも過負荷に陥ることがあったので、Apache 側で mod_limitipconn か mod_bw を利用して、単一の IP アドレスからの過剰な接続を抑制する。

    • mod_limitipconn での例

      mod_limitipconn の場合は、Apache のバーチャルホストの設定部分に下記のような記述を行う。

      <Location />
      <IfModule mod_limitipconn.c>
      MaxConnPerIP 12
      NoIPLimit image/* text/css application/javascript
      </IfModule>
      </Location>

      当然ながら、取り得る値も例なので、サーバのスペックに合わせて要調整。
      上記の例では、同一 IP アドレスからの同時接続数は 12 を上限 (ただし、画像ファイルと CSS ファイル、JavaScript ファイルは除外) とする設定。

  • Apache からの子プロセスの数を制限

    上 2 点での設定でほぼ過負荷の問題は解決できるのだが、まだ一つ問題が残っている。それは 404 の処理。

    WordPress でパーマリンクのカスタマイズを行っている場合、記事や実ファイルが存在しない URL へのアクセスがあった場合でも、一旦 WordPress 上で 404 テンプレートの表示処理が走る。問題は、この 404 ページについては、WP Super Cache ではキャッシュされないので、これに F5 アタックなどをされてしまうと、いとも簡単にサーバのロードアベレージが上昇する。

    そこで、消極的な方法だが、Apache から起動する子プロセス数を制限してしまう。具体的には Apache のバーチャルホスト部分に下記のような設定を行う。

    RLimitNPROC 20 25

    これも取り得る値は要調整。上記は、ソフトリミット 20 プロセス、最大が 25 プロセス。(ただし私自身、実際のところ RLimitNPROC の説明を見ても、ソフトリミットと最大制限値の具体的な意味がよく分からないが、こう設定しておくことで最悪でも 26 プロセス以上は起動されないのであろう、と言う認識でこれを書いているので注意。)
    なお、この方法で CGI や PHP の起動プロセス数を制限するには、suEXEC 等、Apache の実行ユーザとは異なるユーザで CGI や PHP が起動されることが必要。

ほかにも mod-evasive を使ったりあれこれ試行錯誤を行ったが、最終的にはサーバ側でのリソース制限に落ち着いてしまう。(なんかスマートではない)

パーマリンクを WordPress のデフォルトの設定で使用すれば静的に 404 を表示できそうなので、そのまま使用するのが正しいと感じた。

BloggerからWordPressへ移行中

いままで Blogger で公開していた Blog 、「Open the Next」を WordPress へ置き換えを行いました。

移行に関しては、「Blogger to WordPress migration » Alistair's Blog」の内容を大いに参考にさせていただき、リンク切れを限りなく少なくするかたちでできているのではないか思います。

ただ、同一ファイル名がかぶってしまったものがあり、それに関しては、ファイル名を強制的に変更することにより対応しているので、一部に関しては、リンク切れが存在します。これらは追々修正したいところです。