2inc.org || web屋の雑記。トイカメラ。

jqueryでカテゴリごとにメニューの画像を切り替えるTips 2

2009.07.05
0
0

以前にも一度書いてますが、汎用性0で非常に使いにくいものだったので、再度組み直し。良くわからないまま組んだけど、とりあえず動いているっぽいので公開します。

/*========================================

gnav画像を反転させるjquery plugin

========================================*/

function globalNaviCurrent() {
	var url = location.pathname
	var directory = url.split("/");

	if(directory[1]==''){
		var currentDirectory = "/";
	}else if(directory[1]=='category'){
		var currentDirectory = directory[2];
	}else{
		var currentDirectory = directory[1];
	}
	var currentA = $('#header #GlobalNavigation ul li a[@href$=' + currentDirectory + '] img');

	if(imgsrc = currentA.attr("src")){
		var kugiri = imgsrc.split("_n",2);
		var imgsrcCurrent = kugiri[0] + "_r" + kugiri[1];
		currentA.attr({ src: imgsrcCurrent });
	}
};
$(document).ready(globalNaviCurrent);

ルートの直後の階層のパスを取得して判別します（「http://2inc.org/web/html」だったら「web」）。一応wordpress用ってことで、カテゴリーページには「category」というパスが入るようだったので、その判別入れてます。

サイトに会わせて書き換えないといけないのは「currentA」に渡す画像の階層の部分。あとは_nという画像と_rという画像を用意してそれを反転させてます。

参考

JSでナビゲーションをハイライトさせる(web dimension maker )

名前ベースのバーチャルホストでSSL

apache ssl VirtualHost

2009.06.24
0
0

IP ベースのバーチャルホストでは、応答するバーチャルホストへのコネクションを決定するために IPアドレスを使用します。ですから、それぞれのホストに個々に IPアドレスが必要になります。これに対して名前ベースのバーチャルホストでは、クライアントが HTTP ヘッダの一部としてホスト名を告げる、ということに依存します。この技術で同一 IP アドレスを異なる多数のホストで共有しています。

名前ベースのバーチャルホストは通常単純で、それぞれのホスト名とそれに対応する正確な IP アドレスを DNS で設定し、異なるホスト名を区別するように Apache HTTP サーバを設定するだけです。さらに、名前ベースのバーチャルホストは不足する IPアドレスの需要を緩和します。したがって、IP ベースのバーチャルホストを選択すべき特定の理由がなければ名前ベースのバーチャルホストを使うべきです。IP ベースのバーチャルホストを使用することを考慮する理由として、

名前ベースのバーチャルホストに対応していない古いクライアントがある名前ベースのバーチャルホストが働くためには、クライアントはHTTP ホストヘッダを送ってこなければなりません。これは HTTP/1.1 の仕様で要求されていて、すべての現代的なHTTP/1.0 ブラウザでも拡張として実装されています。とても古いクライアントをサポートしつつ、名前ベースのバーチャルホストを行いたい場合は、この文書の最後の方に書かれている解決策になるかもしれない方法を見てください。

名前ベースのバーチャルホストは SSL プロトコルの特徴により、SSL セキュアサーバには使えません。

オペレーティングシステムやネットワーク装置のなかには、別の IP アドレス上でない場合、複数のホストを別扱いできないような帯域管理の方法を実装しているものがあります。

名前ベースのバーチャルホスト

できないらしい。見事にはまってしまったではないかorz

ちなみにバーチャルホストに https で接続要求を行うと、httpd.conf のServerNameで指定したサーバー自身のドキュメントルートを返すため、フルアクセス、つまりhttpをhttpsと置き換えて利用できるhttpsサーバーとしては使う事は出来ないということであり、バーチャルドメインでのSSL運用が出来無いと言う訳ではありません。言葉足らずだったのでこの辺を補足します。

特定のディレクトリに存在する掲示板など、通常のドキュメントルート下に設置できるのであれば、特定ディレクトリでのSSL暗号化保護においてバーチャルドメインによる運用は可能です。例えば、以下の様になります。

httpsでバーチャルドメインに接続した場合、ServerNameで指定した通常のドキュメントルートを返します。つまり、/aaa/というディレクトリを同一ディレクトリです。

https://VirtualDomain.com/aaa/ = https://ServerName.com/aaa/

ディレクトリ/aaa/をバーチャルドメイン、VirtualDomain.com の専用掲示板としてServerName.comのドキュメントルートに設置できるのであれば、SSLの保護に関してはバーチャルドメインによる運用は可能です。

ただし、クライアント認証などは、ServerName.comのサーバー証明書との兼ね合いで制限が出てくると思います。試してません。SSLによる保護は行えますので第三者から通信の盗聴を防ぐ目的は達成されます。

名前ベースのバーチャルホストの欠点

あれ？できるのか？じゃあapacheの設定が悪かったのか…。