2018年3月の仕様変更により、さくらレンタルサーバでもSSL/STL接続（或はHTTPS接続、SNI SSL対応）の判別が普通にできるようになりました。
本記事は、それについての年貢の納め記事（或は狂騒の供養記事）です。
仕様変更対する私の対応と、仕様変更に気づいた経緯を記します。
はじめに
さくらレンタルサーバのSSL/STL化（或はSNI SSL対応）、特にWordPress対応については拙ブログも含めなんやかんやありました。
拙ブログ：「さくらレンタルサーバの共有SSLを使う」（2013年9月21日初稿）
拙ブログ：「さくらレンタルサーバのSSL/STL化についてのエトセトラ」（2017年2月10日初稿）
特に前者の記事はたくさんピンバックを頂けました。
2018年3月からの、さくらレンタルサーバの仕様変更によって狂騒？は幕を閉じましたが、改めて年貢の納め記事を書こうと思います。
さくらインターネットのサポセンの皆様、本当にお疲れ様でした。
私は純粋な第三者ですが、この件に対する対応が少なくなかったであろうことは、想像するに難くありません。
「大変だろうな～」と想像していた2017年2月から（或はChromeやFirefoxが警告する仕様を発表したときから）さぞかし長かったことでしょう。
結論
結論から書きますと、WordPressをさくらレンタルサーバのSSL/STL（或はSNI SSL）に対応するにはwp-config.phpにこういうコードを書きましょう、と言っていたパッチはもう必要ありません。
参考：さくらのサポート情報「レンタルサーバの仕様変更について（2018年3月）」
もう環境変数HTTPSは適切に設定されていますし、HTTP_HOSTにも「www」の有る無しがちゃんと反映されて上がってきます。
「httpsに、またwww付き（或はなし）URLに統一しましょう」というブログ記事にある.htaccessを書けば、さくらレンタルサーバでも正常動作するでしょう。或は同機能のWordPressのプラグインを導入しても、リダイレクトループにはならないでしょう。
それに先のページには「X_SAKURA_FORWARDED_FORを利用せずにHTTPSを利用するようお願いいたします。」とありますので、これまでのパッチを当てていた人は元に戻したほうが良いのでしょうね。
私はもうmod_rewriteの書き方は忘れちゃったし調べるのも面倒なので、PHPのパッチを修正しました。
wp-config.phpに追記したスクリプトを以下に示します。(2018年4月13日：シンプルにしました。)
// If not SSL/TSL, redirect.
if(!array_key_exists('HTTPS', $_SERVER) || $_SERVER['HTTPS']==='' || $_SERVER['HTTPS']==='off' ) {
header('Location: https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'], true, 301 );
exit();
}
2行で普通にHTTPSか判定して、そうでなければhttps付きに転送しているだけです。(URLが「www.」付き、或いはなしの転送はWordPress本体がしてくれるので必要ありません。)
3行の「301」は、テスト段階では「302」にしてください。その間にアクセスしたユーザーのブラウザに間違った転送先がキャッシュされてしまうかもしれませんので。
このコードはもちろんさくら以外でも使えると思います。.htaccessに書くかPHPに書くかは各位の得意なほうにすればよいのでしょう。
記事の修正
私はさくらのサポセンからメールを頂く立場にありませんので、さくらさんの仕様変更に気が付いたのは2018年4月5日です。
先の2つの記事の先頭に、「もう過去の情報」の旨を追記しました。
そこで気が付いたのですが、4月4日に２つの記事からピンバックがありました。😅
一応ピンバックに返信はしてみたんですが、これって相手に届くのでしょうか？
ピンバックの先の記事に行ってコメントするまではしませんが。
仕様変更に気づいた理由
メールを頂く立場にない私がレンタルサーバ仕様変更に気が付いた経緯を書こうと思います。
さくらレンタルサーバに、内部でWebAPIをコールするPHPプログラムを上げていました。
4月1日に動作を確認したのですが、4月5日にエラーで動かなくなっていました。
WebAPIコールのレスポンスを見ると、500 Bad Requestが帰っており、その送り主として「nginx」とありました。
「さくらのサーバってnginxだったっけ？」
で、仮にこれまでApacheだったものがnginxに変わった場合、エラーになりそうなところはどこか考えました。
WebAPIの呼出しのところは以下のように書いています。（実際はmethodとかheaderも変数です。）
$request = array( 'http' => array( 'method' => 'post', 'header' => "Content-Type: application/json\r\n", 'content'=> json_encode($data), 'ignore_errors' => true ) ); $context = stream_context_create($request); $response = file_get_contents($url, false ,$context);
ここで思ったのは「”post” は大文字のほうが良いかも…」
これがビンゴ。サーバが変わったのが原因だろうとアタリを付けて管理者に聞き、仕様変更を知った次第です。
実際にサーバが変わったのか？
HTTPのResponse headerを見ると「Server: nginx」とありますので、フロントエンド（リバースプロキシ）がnginxなのは間違いないでしょう。
試しに「http://」でアクセスしてみても、Response headerには「nginx」とありました。
さらにPHPの環境変数をみると、$_SERVER[‘SERVER_SOFTWARE’] の値は「Apache」でした。
ということで、もしかしたらプログラムが動いているサーバはApacheのままで、リバースプロキシがnginx、今まではhttpsだけがリバースプロキシを介していたのが、httpでも介するようになったのでは、と、nginxは名前だけしか知らないプログラマーレベルで推測しています。
答え合わせで以下のページを見ましたら、（今でも）「サーバソフトウェア名 Apache2.4.x系」とありました。
参考：さくらのサポート情報「【さくらのレンタルサーバ】基本仕様」
まとめ
さくらレンタルサーバ上のWordPressサイトの、SSL/STL化問題は終焉を迎えました。
しかし4月4日時点で拙ブログにピンバックがあることから、「HTTP_X_SAKURA_FORWARDED_FOR」は今後もしばらくは使われるでしょう。
以前の記事にも書きましたが、ブログ記事、特に古い記事を盲信するのは止めましょう。
公式サイトで裏をとりましょう。
或は自身で実験して確かめましょう。
この記事もPHPの環境変数を確かめて書いてますよ。但し2018年4月6日時点での。
最後に繰り返しになりますが、さくらインターネットのサポセンの皆様、お疲れ様でした。🍻
（公式サイトでのHTTP_X_SAKURA_FORWARDED_FORへの言及は初めて見ました。😆）