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になっています。
これで困る事として、とりあえずプラグインやテーマが読み込むJavaScriptやcssのパスが、httpになってしまい、httpsなページからhttpなリソースを読み込んでいるという警告が出てしまうという事があります。もちろんこれだけじゃなく、他にもあると思いますが。
あと、多分他のフレームワークとかCMSとかも、$_SERVER['HTTPS']
を見てるものはいくつかあると思うので、coreserverの共用SSLをそのまま使おうとするとハマるかもしれない。
解決策は不明
今回は、たまたま気になって調べただけで、coreserverの共用SSLをWordpressで使いたいってわけじゃないので、解決策は調べてません。is_ssl()
にフックが無いので、簡単には解決出来なさそうな気がしますが。
その他の気になる点
coreserverは確か、独自SSLもオプションで使えたと思います。これが共用SSLと同じような動きをするかも、もしcoreserverで何かするなら確認しておきたいところ。