MODX JAPAN

-----
ご利用のサーバ：KDDI S20
MODXのバージョン：1.0.6J-r8
PHPのバージョン：5.2.8
MySQLのバージョン：5.0.45
ブラウザ： Windows7 IE9、iPhone、Android
-----

CSSが効かず、リンクもすべて切れた状態になっていたページがあり、
ソースを見たところベースタグが となっていました。

フレンドリーURLを使用するため、
各種テンプレートに のコードを入れています。

他のページは正しいURLが入っていたのですが、
なぜか、このページだけ[(site_url)]に異常な値が入っていました。

サイトをリフレッシュすれば、とりあえずの回避はできそうですが、
再発を防止したいので、なんとか原因をつきとめられないかと思っています。

どんなことでも良いので、何か参考になりそうな情報はありませんでしょうか？

補足です。

グローバル設定は、以下のようになっています。
・サイトのURL：空欄
・ベースURL：「/」

また、当該リソースの設定は、以下のようになっています。
・キャッシュ制御を行なう：「はい」

サイトのURLが空欄の場合はsite_urlを動的に生成しますが、この処理はmanager/includes/initialize.phpで行なっています。

ありがとうございます。

とりあえず、再現できそうな気がしないので、
ソースを追ってみました。

assign_site_urlの を見る限り、
base_urlは「/」のはずなので、 が、
空か、「:」か「/」の文字のみだった場合に、
[(site_url)]が「http:/」になるということはわかりました。

どういう状況になると、こういうことが起こるのかなぁ…？？？

壊れたキャッシュが生成された時刻のアクセスログを確認すると、
********.compute.amazonaws.com
からの「HEAD」リクエストでした。

もしかして、
HEADリクエストに対して（もしくは、ボットに対して）は、
$_SERVER['HTTP_HOST']
が空になるとかあるのかなぁ？？？

ちなみに、
HEADリクエストの場合でも、MODXはページを生成して返すんですよね？

HEADリクエストのことをよく知らないので調べてみましたが、GETやPOSTのようなものなんですね。GETに近いけど本文は返さない、みたいな。
initialize.phpではなくパーサ本体に入ってからの処理になりますが、おそらく想定外の挙動になると思います。（でも今回の件とは関係なさそう）

さらに補足です。

問題が起こったページは、サイトのトップページで、
問題のキャッシュが生成される数分前にもアクセス「GET / HTTP/1.1」があり、
この時間帯、管理操作は行っていないので、
「********.compute.amazonaws.com」からの「HEAD / HTTP/1.0」で、
キャッシュが生成されているのも不思議です。

この件、後になって気づきました。f(^^;;

HTTP_HOSTって、
アクセス側のHTTPリクエストヘッダ「Host」の情報でしたね。

実際、ツールを使って「Host」に変な値を入れてリクエストしたところ、
「[(site_url)]」は変な値になりました。

HTTP_HOSTが使えないからといって、
SERVER_NAMEもバーチャルドメインでは使えなかったりするので…

結局
グローバル設定「サイトのURL」の設定で対応しました。