coreserverの共用SSLはWordpressのis_ssl()で判別できない

Wordpressプラグインについて調べていて、たまたまこの現象に行き当たりました。知りたかった事ではなかったけど、これはこれでメモしておきたい。

<?php
/**
 * Determine if SSL is used.
 *
 * @since 2.6.0
 *
 * @return bool True if SSL, false if not used.
 */
function is_ssl() {
	if ( isset($_SERVER['HTTPS']) ) {
		if ( 'on' == strtolower($_SERVER['HTTPS']) )
			return true;
		if ( '1' == $_SERVER['HTTPS'] )
			return true;
	} elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
		return true;
	}
	return false;
}
http://svn.automattic.com/wordpress/tags/3.3.1/wp-includes/functions.php

Wordpressでは、このis_ssl()関数でhttpsなアクセスかどうかを判別してます。coreserverの共用SSLでは、この判別に使う$_SERVER['HTTPS']が、たとえSSLでも存在しないという謎の仕様になっているようです。じゃぁ$_SERVER['SERVER_PORT']はというと、これもどういうわけか80になっています。

これで困る事として、とりあえずプラグインやテーマが読み込むJavaScriptcssのパスが、httpになってしまい、httpsなページからhttpなリソースを読み込んでいるという警告が出てしまうという事があります。もちろんこれだけじゃなく、他にもあると思いますが。

あと、多分他のフレームワークとかCMSとかも、$_SERVER['HTTPS']を見てるものはいくつかあると思うので、coreserverの共用SSLをそのまま使おうとするとハマるかもしれない。

解決策は不明

今回は、たまたま気になって調べただけで、coreserverの共用SSLWordpressで使いたいってわけじゃないので、解決策は調べてません。is_ssl()にフックが無いので、簡単には解決出来なさそうな気がしますが。

判別に使えそうなキー
["HTTP_VIA"]=>
  string(44) "1.1 ss1.coressl.jp:3128 (squid/2.5.STABLE14)"

ざっとvar_dump($_SERVER)を眺めると、$_SERVER['HTTP_VIA']が判別に使えそうです。自分のプログラムだったら、これを使ってどうとでも書けそうだけど、Wordpressに組み込まれた関数となると、やはりWordpress本体に手を入れないと難しそう。

その他の気になる点

coreserverは確か、独自SSLもオプションで使えたと思います。これが共用SSLと同じような動きをするかも、もしcoreserverで何かするなら確認しておきたいところ。

環境

coreserver
Apache 1.3.37
php 5.2.5