JP6151508B2 - 中継装置、中継方法および中継プログラム - Google Patents

Description

本発明は、中継装置、中継方法および中継プログラムに関する。

企業内のＬＡＮなどにおいて、インターネットに直接接続できないクライアントからのリクエストをクライアントに代わって目的のサーバに送信する処理を行うものを、一般的にはプロキシと呼ばれる。このプロキシはクライアントとインターネットとの接点に通常設置される。一方、インターネットと目的のサーバとの接点にプロキシを設置して、外部からサーバへのリクエスト要求があった場合にリクエスト先のサーバに代わって応答処理を行うものを一般的にはリバースプロキシと呼ばれる。このリバースプロキシは不特定多数のクライアントからの要求に対して、目的のサーバが本来行うはずの応答を肩代わりすることにより、目的のサーバの負担を軽減させることができる。また、リバースプロキシで目的のサーバへのアクセスを制限することにより目的のサーバのセキュリティを高めることもできる。

リバースプロキシに関する発明としては、たとえば、サーバによって設定されたＣｏｏｋｉｅを有効に使用できるように、Ｓｅｔ−Ｃｏｏｋｉｅヘッダを書き換える機能を備えたものが知られている（特許文献１）。

特開２００４−９４９０５号公報

ところで、ユーザがＷｅｂページへアクセスする際にはＷｅｂブラウザなどのユーザエージェントにその目的となるＷｅｂサーバ（以下、目的となるＷｅｂサーバを「オリジンサーバ」という。）のＵＲＩ（Uniform Resource Identifier）を指定して表示させることができる。オリジンサーバが保持しているＷｅｂページを構成する各コンテンツには、通常、起点となる現在位置から目的のファイルやフォルダまでの道筋を記述する方式（以下、この記述方式を単に「相対パス」という。）でのリンクが記述されているが、装置内の最上位階層から目的のファイルやフォルダまでのすべての道筋を記述する方式（以下、この記述方式を単に「絶対パス」という。）でのリンクが記述されている場合もある。ここで、オリジンサーバの代理としてリバースプロキシが構築されている場合であって、目的のＷｅｂページ内のコンテンツへのリンクがオリジンサーバでの絶対パスで記述されていると、リバースプロキシがオリジンサーバに対して目的のコンテンツを要求できない場合がある。以下、この不具合について具体的に説明する。

Ｗｅｂブラウザから要求されるオリジンサーバのＵＲＩには、要求の宛先となるオリジンサーバの他に、オリジンサーバおよびリバースプロキシのいずれかにて解釈される文字列が含まれている。たとえば、Ｗｅｂブラウザに下記の記述（１）のＵＲＩが指定されたとする。
http://www.dit.co.jp/origin/company/index.html ・・・（１）
この記述（１）に示すＵＲＩで説明すると、“/origin/company/index.html”というパス部分がオリジンサーバおよびリバースプロキシのいずれかにて解釈される文字列に相当する。また、このパス部分にオリジンサーバの識別子である“/origin”が埋め込まれていることで、リバースプロキシが「どのオリジンサーバへの要求か」を把握して、Ｗｅｂブラウザから要求されたコンテンツの取得先のオリジンサーバを決定することができる。つまり、記述（１）に示すＵＲＩでの“/origin”はリバースプロキシが解釈する部分であるので、オリジンサーバによって直接解釈される文字列は“/company/index.html”となる。そのため、（１）の要求をＷｅｂブラウザから受信したリバースプロキシは、要求先のオリジンサーバに対して“/origin”を削除した下記の記述（２）の要求を送信して、オリジンサーバから“index.html”を取得して、Ｗｅｂブラウザへ応答を返す。これにより、Ｗｅｂブラウザ上では“index.html”が表示されることになる。
/company/index.html ・・・（２）

次に、Ｗｅｂブラウザが上記の記述（１）の要求で取得した“index.html”に記述されている画像コンテンツへのリンクが相対パスで記述されているとする。たとえば、“index.html”内に下記の記述（３）のリンクがあるとする。
＜Ａ ＨＲＥＦ=“baz.jpg”＞写真＜/a＞ ・・・（３）
そして、Ｗｅｂブラウザにて表示されるＷｅｂページ上でこの記述（３）に示すリンクがクリックされたとする。このとき、上記のリンクで指定された画像コンテンツについて、Ｗｅｂブラウザは“http://www.dit.co.jp/origin/company/”下にある“baz.jpg”であると認識するため、リバースプロキシへのＵＲＩ要求は、下記の記述（４）となる。
http://www.dit.co.jp/origin/company/baz.jpg ・・・（４）

Ｗｅｂブラウザから上記の記述（４）の要求を受信したリバースプロキシは、記述（４）の要求先のオリジンサーバに対して、“/origin”を削除した下記の記述（５）の要求を送信して、オリジンサーバから“baz.jpg”を取得して、Ｗｅｂブラウザに応答を返す。これにより、Ｗｅｂブラウザ上では“baz.jpg”の画像コンテンツが表示されることになる。
/company/baz.jpg ・・・（５）

一方、Ｗｅｂブラウザが上記の記述（１）に示すＵＲＩ要求で取得した“index.html”に記述されている画像コンテンツへのリンクがオリジンサーバにおける絶対パスで記述されているとする。たとえば、“index.html”内に下記の記述（６）のリンクがあるとする。
＜Ａ ＨＲＥＦ=“/img/baz.jpg”＞ 写真＜/a＞ ・・・（６）
そして、Ｗｅｂブラウザで表示されるＷｅｂページ上でこの記述（６）のリンクがユーザによりクリックされたとする。

Ｗｅｂブラウザは、上記の記述（５）のＵＲＩ要求をする場合、“http://www.dit.co.jp/”に存在するコンテンツであると認識するため、リバースプロキシへのＵＲＩ要求は、下記の記述（７）となる。
http://www.dit.co.jp/img/baz.jpg
・・・（７）
この記述（７）の要求を受信したリバースプロキシは、「どのオリジンサーバへの要求か」を把握するパス部分がこの要求に含まれていないため、オリジンサーバが有しているはずの“baz.jpg”を取得することができない。

すなわち、オリジンサーバ側で保有するコンテンツのリンクが絶対パスで記述されている場合、リバースプロキシ側でどのオリジンサーバへの要求であるかを判別することができなくなり、Ｗｅｂブラウザからの要求を正しく転送させることができなくなる。

本発明は、上述の事情に鑑みてなされたものであり、オリジンサーバ側で保有するコンテンツのリンクが絶対パスで記述されている場合であっても、オリジンサーバへと転送させることができる中継装置、中継方法および中継プログラムを提供することを目的とする。

上述の課題を解決するために、本発明の一側面は、中継装置に関するものである。すなわち、外部ネットワークに属するユーザエージェントからの要求を受け付けて、ユーザエージェントの要求先に応じて、内部ネットワークに属する複数のオリジンサーバのいずれかへと要求を中継する中継装置であって、要求には、ユーザエージェントに対して中継装置が予め付与した情報が記述されているヘッダ、あるいはユーザエージェントがオリジンサーバへの要求を行ったリンク元を示す情報が記述されているヘッダが含まれており、ユーザエージェントからの要求に含まれるＵＲＩと、ヘッダに含まれるＵＲＩとを比較して、ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定する判定部と、判定部の判定結果に応じてユーザエージェントからの要求に含まれるＵＲＩを書き換える処理部とを有することを特徴とする。

また、上述した中継装置であって、判定部は、ユーザエージェントから送信される要求の種類に応じて、要求以前にユーザエージェントに対して中継装置が予め付与した情報が記述されているヘッダ、および要求の直前にユーザエージェントが要求を行ったリンク元を示す情報が記述されているヘッダのいずれかを参照して、ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定することができる。

また、上述した中継装置のいずれかであって、ユーザエージェントからの要求に中継装置が予め付与した情報が記述されているヘッダがないときは、その要求の応答をユーザエージェントに送信する際に、Ｓｅｔ−Ｃｏｏｋｉｅヘッダを付与するヘッダ付与部を有し、処理部は、ユーザエージェントから、ヘッダ付与部により付与されたＳｅｔ−Ｃｏｏｋｉｅヘッダにて指定したＣｏｏｋｉｅ名が含まれているＣｏｏｋｉｅヘッダを有する要求があった場合に、その要求に含まれるＵＲＩの記述が、その要求のＣｏｏｋｉｅヘッダに含まれるＣｏｏｋｉｅ名に対応するＣｏｏｋｉｅ値の記述で始まっていない場合には、ユーザエージェントからの要求に含まれるＵＲＩの書き換えを行うことができる。

また、上述した中継装置のいずれかであって、判定部は、ユーザエージェントからの要求の直前にユーザエージェントがオリジンサーバへの要求を行ったリンク元を示す情報が記述されているＲｅｆｅｒｅｒヘッダを参照し、ユーザエージェントからの要求に含まれるＵＲＩと、Ｒｅｆｅｒｅｒヘッダに含まれるＵＲＩの一部とを比較して、両者が一致しない場合にユーザエージェントからの要求に含まれるＵＲＩの書き換えを行うことができる。

また、本発明の一側面は、中継方法に関するものである。すわなち、本発明の中継方法は、外部ネットワークに属するユーザエージェントからの要求を受け付けて、ユーザエージェントの要求先に応じて、内部ネットワークに属する複数のオリジンサーバのいずれかへと要求を中継する中継装置が実行する中継方法であって、要求には、ユーザエージェントに対して中継装置が予め付与した情報が記述されているヘッダ、あるいはユーザエージェントがオリジンサーバへの要求を行ったリンク元を示す情報が記述されているヘッダが含まれており、ユーザエージェントからの要求に含まれるＵＲＩと、ヘッダに含まれるＵＲＩとを比較して、ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定する判定ステップと、判定ステップの判定結果に応じてユーザエージェントからの要求に含まれるＵＲＩを書き換える処理ステップとを有するものである。

また、本発明の一側面は、中継プログラムに関するものである。すわなち、本発明の中継プログラムは、コンピュータを、外部ネットワークに属するユーザエージェントからの要求を受け付けて、ユーザエージェントの要求先に応じて、内部ネットワークに属する複数のオリジンサーバのいずれかへと要求を中継する中継装置として機能させるための中継プログラムであって、要求には、ユーザエージェントに対して中継装置が予め付与した情報が記述されているヘッダ、あるいはユーザエージェントがオリジンサーバへの要求を行ったリンク元を示す情報が記述されているヘッダが含まれており、コンピュータを、ユーザエージェントからの要求に含まれるＵＲＩと、ヘッダに含まれるＵＲＩとを比較して、ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定する判定手段と、判定手段の判定結果に応じてユーザエージェントからの要求に含まれるＵＲＩを書き換える処理手段として機能させるためのものである。

本発明によると、オリジンサーバ側で保有するコンテンツのリンクが絶対パスで記述されている場合であっても、ユーザエージェントからのＵＲＩ要求をオリジンサーバへと転送させることができる中継装置、中継方法および中継プログラムを提供することができる。

本発明の第１実施形態に係るリバースプロキシサーバ１０を含むパーソナルプラットフォームシステムの全体構成を示す図である。 図１に示すリバースプロキシサーバ１０の機能的な構成を示すブロック図である。 図１に示すリバースプロキシサーバ１０が実行する中継処理の一例を示すフローチャートである。 図１に示すリバースプロキシサーバ１０が実行する中継処理の一例を示すフローチャートである。 本発明の第２実施形態に係るリバースプロキシサーバ１０Ａの機能的な構成を示すブロック図である。 図５に示すリバースプロキシサーバ１０Ａが実行する中継処理の一例を示すフローチャートである。 図５に示すリバースプロキシサーバ１０Ａが実行する中継処理の一例を示すフローチャートである。 図１および図５で説明したリバースプロキシサーバ１０，１０Ａのハードウェア構成の一例を示す図である。

以下、本発明の中継装置の一実施の形態であるリバースプロキシサーバ１０，１０Ａについて図面を参照しながら説明する。なお、本発明の中継方法および中継プログラムについては、リバースプロキシサーバ１０、１０Ａの動作およびリバースプロキシサーバ１０，１０Ａにインストールされた中継プログラムを例として説明する。しかしながら、以下で説明する実施の形態は、本発明を具体化した一例であって、本発明を限定するものではない。

[第１実施形態]
図１は、本発明の第１実施形態に係るリバースプロキシサーバ１０を含むパーソナルプラットフォームシステムの全体構成を示す図である。このパーソナルプラットフォームシステムは、Ｗｅｂブラウザ１００からインターネット１１０およびリバースプロキシサーバ１０を介して、ユーザの宅内のＬＡＮ（Local Area Network）１２０に接続されている機器２００Ａ、２００Ｂ、２００Ｃ（以下、個々に区別する必要がない場合、単に「機器２００」という。）に外部から安全にアクセスすることができるシステムである。なお、図示は省略するが、インターネット１１０側からリバースプロキシサーバ１０へのアクセスについては、リバースプロキシサーバ１０の特定のポート宛に対する通信であって、特定のＩＰアドレスが発信元となっている場合にのみ通信を許可する設定がなされたファイアウォールが予め構築されているものとする。

Ｗｅｂブラウザ１００は、請求項に記載のユーザエージェントの一例であり、図１に示すパーソナルプラットフォームシステムのユーザが保有しているノートＰＣやスマートフォンなどの情報処理装置（いずれも不図示）にインストールされている。ユーザは、外出先などでＷｅｂブラウザ１００を起動し、リバースプロキシサーバ１０を介して外部から機器２００に接続して、Ｗｅｂベースで閲覧可能に構築されているコンテンツ（たとえば、画像データ、映像データ、テキストデータなど）を閲覧することができる。

リバースプロキシサーバ１０は、請求項に記載の中継装置の一例であり、いわゆるリバースプロキシ機能を有するサーバである。リバースプロキシサーバ１０は、ユーザの宅内に後述する機器２００と共にＬＡＮ１２０に接続されており、ユーザが起動したＷｅｂブラウザ１００からのＵＲＩ要求を機器２００に代わって応答すると共に、要求先の機器２００に対してＵＲＩ要求を転送して、機器２００からの応答をＷｅｂブラウザ１００へ返す装置である。なお、このリバースプロキシサーバ１０では、機器２００が外部にコンテンツを公開するためのパス名と（以下、このパス名を「公開パス名」という。）、リバースプロキシサーバ１０のディレクトリ上で示される仮想的なパス名（以下、このパス名を「仮想パス名」という。）との書き換えをするための関係情報が予め設定されており、Ｗｅｂブラウザ１００からの要求に応じて、機器２００が解釈できる形式となるように適宜変換して転送するように構成されている。

機器２００は、たとえば、ネットワークカメラ、ビデオレコーダ、ＮＡＳ（Network Attached Storage）などの電子機器であり、図１に示すパーソナルプラットフォームシステムを利用するユーザの宅内に構築されているＬＡＮ１２０に接続されている。なお、機器２００は、それぞれ独自のディレクトリ構成およびコンテンツを有しており、上述した仮想パスに関連付けられた公開パス下にコンテンツが保存されており、リバースプロキシサーバ１０を介して外部から接続できるように構成されている。なお、図１に示すパーソナルプラットフォームシステムでは、ユーザはＬＡＮ１２０に接続されている不図示のＰＣ等からリバースプロキシサーバ１０に対して機器２００についての登録処理を予め実行しているものとする。

図２は、図１に示すリバースプロキシサーバ１０の機能的な構成を示すブロック図である。リバースプロキシサーバ１０は、フィルタ部１１とリバースプロキシ部１２とを有している。

フィルタ部１１は、Ｗｅｂブラウザ１００からの要求を受け付けると共に、受け付けた要求に含まれるＵＲＩを書き換えるか否かを判定する。また、フィルタ部１１は、受け付けた要求に含まれるＵＲＩの書き換えの必要があると判定した場合には、適切なＵＲＩとなるように書き換えて後述するリバースプロキシ部１２を介して機器２００へと転送する。また、フィルタ部１１は、リバースプロキシ部１２を介して機器２００から受け取った応答をＷｅｂブラウザ１００へと転送する。これらの機能を実現するために、フィルタ部１１は、図２に示すように、判定部２１と、Ｃｏｏｋｉｅ付与部２２と、処理部２３と、要求発行部２４と、応答発行部２５とを有している。

判定部２１は、Ｗｅｂブラウザ１００からの要求に、後述するＣｏｏｋｉｅ付与部２２により付与されたＣｏｏｋｉｅ名があるか否かを判定する。また、判定部２１は、Ｃｏｏｋｉｅ名があると判定した場合には、このＣｏｏｋｉｅ名が記載されているＣｏｏｋｉｅヘッダに含まれるＣｏｏｋｉｅ値に基づいてＷｅｂブラウザ１００からの要求が仮想パス名の先頭部分で始まっているか否かを更に判定して、この判定結果に応じて、受け付けた要求に含まれるＵＲＩを書き換えるか否かを決定する。

たとえば、判定部２１は、Ｗｅｂブラウザ１００からの要求に、後述するＣｏｏｋｉｅ付与部２２により付与されたＣｏｏｋｉｅ名が含まれており、かつこの要求に含まれるＵＲＩがＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分で始まっている場合には、この要求に含まれるＵＲＩを後述するリバースプロキシ部１２においてそのまま解釈しても問題がないので書き換える必要がないと判断し、後述する要求発行部２４へとそのまま受け渡す。

一方、判定部２１は、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩに、後述するＣｏｏｋｉｅ付与部２２により付与されたＣｏｏｋｉｅ名があるが、この要求に含まれるＵＲＩがＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分で始まっていない場合には、この要求に含まれるＵＲＩを後述するリバースプロキシ部１２がそのまま解釈すると、どの機器２００へ転送すればよいのか判断できないので、この要求に含まれるＵＲＩは書き換える必要があると判断し、後述する処理部２３に対してＵＲＩの書き換え処理の実行を指示する。

また、判定部２１は、Ｗｅｂブラウザ１００からの要求にＣｏｏｋｉｅヘッダが含まれていない場合には、機器２００に対して初めての接続であるか、またはＣｏｏｋｉｅ情報が何らかの理由で消滅していると判断し、後述するＣｏｏｋｉｅ付与部２２に対して、この要求に対する応答のヘッダにＳｅｔ-Ｃｏｏｋｉｅヘッダを付与するように指示をする。これにより、この要求以降に発生するＷｅｂブラウザ１００からの要求に対しては後述するＣｏｏｋｉｅ付与部２２がＳｅｔ-Ｃｏｏｋｉｅヘッダにて指示したＣｏｏｋｉｅ名およびＣｏｏｋｉｅ値が付与されることになる。

Ｃｏｏｋｉｅ付与部２２は、判定部２１からの指示により、Ｗｅｂブラウザ１００からのＵＲＩ要求に対する応答のヘッダにＳｅｔ-Ｃｏｏｋｉｅヘッダを付与する。なお、このＳｅｔ-Ｃｏｏｋｉｅヘッダにはリバースプロキシサーバ１０が付与したＣｏｏｋｉｅ名とＣｏｏｋｉｅ値とが記載される。Ｃｏｏｋｉｅ名とＣｏｏｋｉｅ値は、たとえば、下記の記述（８）に示すように記載される。なお、このＣｏｏｋｉｅ名には他のシステムが付与するＣｏｏｋｉｅ名と衝突しない（衝突する可能性が十分に低い）適当な文字列が設定されることが好ましい。また、Ｃｏｏｋｉｅ値には、機器２００の仮想パス名の先頭部分が得られる文字列（たとえば、“／orijin”など）が記載される。
Set-Cookie:Ｃｏｏｋｉｅ名=Ｃｏｏｋｉｅ値 ・・・（８）

処理部２３は、上述した判定部２１からの指示により、ＵＲＩ要求を書き換える処理を実行する。なお、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩを書き換える処理については後述するフローチャート（図４）で説明する。

要求発行部２４は、上述した処理部２３により書き換えられた後のＵＲＩ要求、あるいは、判定部２１からそのまま受け渡されたＵＲＩ要求を後述するリバースプロキシ部１２へと受け渡す。

応答発行部２５は、後述するリバースプロキシ部１２から受け渡された機器２００からの応答（Ｗｅｂブラウザ１００からのＵＲＩ要求の応答に相当）をＷｅｂブラウザ１００へと転送する。

リバースプロキシ部１２は、フィルタ部１１から受け渡されたＵＲＩ要求を、機器２００側のディレクトリ構成にあった形式に変換して機器２００へ転送すると共に、転送したＵＲＩ要求に対する機器２００からの応答を受け取って、フィルタ部１１へと転送する機能を有している。これらの機能を実現するために、リバースプロキシ部１２は、要求発行転送部３１と、応答発行転送部３２と、機器情報登録テーブル３３とを有している。

要求発行転送部３１は、上述したフィルタ部１１から受け渡されたＵＲＩ要求を機器２００側のディレクトリ構成にあった形式に変換したものを機器２００へと転送する。具体的には、要求発行転送部３１は、要求発行部２４から受け渡されたＵＲＩ要求が仮想パス名の場合には、後述する機器情報登録テーブル３３、あるいはＷｅｂブラウザ１００からの要求に含まれるＣｏｏｋｉｅヘッダを参照して、転送先の機器２００の仮想パス名の先頭部分に該当する文字列を除去することによって公開パス名に変換して目的の機器２００へと転送する。

応答発行転送部３２は、機器２００からの応答を受信した場合に、上述したフィルタ部１１へと転送する。

機器情報登録テーブル３３には、機器２００の公開パス名とリバースプロキシサーバ１０上の仮想パス名とを適切に書き換えるための関係情報が記憶されているテーブルである。リバースプロキシサーバ１０では、機器情報登録テーブル３３、あるいはＷｅｂブラウザ１００からの要求に含まれるＣｏｏｋｉｅヘッダを参照することにより、どの機器２００に対してのＵＲＩ要求であるのかを把握して、正しい転送先を決定することができる。

（通信処理）
続いて、リバースプロキシサーバ１０が実行する中継処理について説明する。なお、リバースプロキシサーバ１０では、Ｗｅｂブラウザ１００からＵＲＩ要求が送信されてくると、そのＵＲＩ要求にＣｏｏｋｉｅ付与部２２により付与されたＣｏｏｋｉｅ名の有無に応じてその後の処理が異なるため、それぞれ別々のフローチャートを示して説明することとする。図３および図４は、図１に示すリバースプロキシサーバ１０が実行する中継処理の一例を示すフローチャートである。

まず、図３に示すフローチャートを参照してＷｅｂブラウザ１００からの要求に含まれるＵＲＩにＣｏｏｋｉｅ付与部２２が予め付与するＣｏｏｋｉｅ名がない場合の処理を説明する。この図３に示す中継処理は、たとえば、Ｗｅｂブラウザ１００が起動されてから機器２００に初めてアクセスする場合に実行される処理手順である。

図３のステップＳ１において、Ｗｅｂブラウザ１００は、下記の（９）のＵＲＩ要求を発行して、リバースプロキシサーバ１０に対してＵＲＩ要求を送信する。なお、このＵＲＩ要求にはリバースプロキシサーバ１０を示すホスト情報として“ｐｒｏｘｙ”が設定されている。
ＧＥＴ /origin/index.html HTTP/1.1
Ｈｏｓｔ：ｐｒｏｘｙ ・・・（９）

ステップＳ２において、リバースプロキシサーバ１０のフィルタ部１１は、上記の（９）のＵＲＩ要求を受信すると、このＵＲＩ要求にＣｏｏｋｉｅ付与部２２がＳｅｔ−Ｃｏｏｋｉｅヘッダにより指定した情報であるＣｏｏｋｉｅ名（図３ではＣｏｏｋｉｅ名はＰとする）があるか否かを判定する。なお、この例の場合、このステップＳ２において、フィルタ部１１により、ステップＳ１で送信されたＵＲＩ要求に予め付与したＣｏｏｋｉｅ名がないと判定され、処理はステップＳ３に移行する。

ステップＳ３において、フィルタ部１１は、ステップＳ１で送信されたＵＲＩ要求については書き換える必要がないため、リバースプロキシ部１２にそのまま受け渡す。

ステップＳ４において、リバースプロキシ部１２は、ステップＳ３でフィルタ部１１から受け渡されたＵＲＩ要求を、機器２００のディレクトリ構成にあった形式に変換した下記の記述（１０）に示すＵＲＩ要求を機器２００に対して発行する。具体的には、リバースプロキシサーバ１０側でどの機器２００であるかを判別する部分である“/origin”を除去したＵＲＩ要求を機器２００に対して発行する。なお、以後、このリバースプロキシサーバ１０側でどの機器２００であるかを判別する部分のことを「転送起点」と呼ぶことにする。
ＧＥＴ /index.html HTTP/1.1
Ｈｏｓｔ：orijin ・・・（１０）

ステップＳ５において、機器２００は、ステップＳ４のＵＲＩ要求に対する応答を発行する。具体的には、“index.html”を構成するデータをリバースプロキシサーバ１０に対して送信する。

ステップＳ６において、リバースプロキシ部１２は、ステップＳ５で送信された機器２００からの応答を受信すると、その応答をフィルタ部１１へと受け渡す。

ステップＳ７において、フィルタ部１１は、ステップＳ６で受け渡された機器２００からの応答は、ステップＳ１でＷｅｂブラウザ１００が送信したＵＲＩ要求に対する応答であるため、Ｗｅｂブラウザ１００へ送信する応答ヘッダにＳｅｔ-Ｃｏｏｋｉｅヘッダを付与したものをＷｅｂブラウザ１００へと戻す。下記の記述（１１）に、その一例を示す。
ＨＴＴＰ/１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｘｘｘｘ
Ｃｏｎｎｅｃｔｉｏｎ：ｃｌｏｓｅ
Ｓｅｔ−Ｃｏｏｋｉｅ：ｐ＝/origin ・・・（１１）

上記の記述（１１）に示した応答を受信したＷｅｂブラウザ１００では、以後、目的の機器２００へＵＲＩ要求を送信する際には、このＳｅｔ-Ｃｏｏｋｉｅヘッダにて指示された情報をＣｏｏｋｉｅヘッダに付与して送信することになる。

続いて、図４に示すフローチャートを参照して、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩにＣｏｏｋｉｅ付与部２２にて指示された情報であるＣｏｏｋｉｅ名がある場合の中継処理について説明する。なお、図４に示す中継処理は、上述した図３の中継処理を一度実行した後に、表示されている“index.html”というＷｅｂページ内の“index１.html”というリンクがユーザによりクリックされたものとして説明する。

ステップＳ１０において、Ｗｅｂブラウザ１００は、以下の記述（１２）のＵＲＩ要求をリバースプロキシサーバ１０に対して送信する。なお、このステップＳ１０に示したＵＲＩ要求は、絶対パスで記載されている。また、このステップＳ１０に示したＵＲＩ要求には、リバースプロキシサーバ１０から予め付与されたＣｏｏｋｉｅ名（“Ｐ”）が記載されたＣｏｏｋｉｅヘッダと、リンク元のＵＲＩ情報が記載されたＲｅｆｅｒｅｒヘッダとが含まれている。
ＧＥＴ /index１.html HTTP/1.1
Ｈｏｓｔ：ｐｒｏｘｙ
Ｃｏｏｋｉｅ：ｐ＝/origin
Ｒｅｆｅｒｅｒ：http://proxy/origin/index.html ・・・（１２）

ステップＳ１１において、リバースプロキシサーバ１０のフィルタ部１１は、ステップＳ１０で送信された要求を受信すると、この要求にＣｏｏｋｉｅ付与部２２により予め付与したＣｏｏｋｉｅ名があるか否かを判定する。ステップＳ１０で説明したように、ステップＳ１０で送信されたＵＲＩ要求には予め付与したＣｏｏｋｉｅ名として、“Ｐ”があるため、フィルタ部１１は、更にステップＳ１２の判定に移行する。

ステップＳ１２において、フィルタ部１１は、Ｗｅｂブラウザ１００からのＵＲＩ要求（すなわち、ＧＥＴメソッドで始まる部分）がＣｏｏｋｉｅヘッダに記載されているＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分で始まるか否かを判定する。この例では、Ｗｅｂブラウザ１００からのＵＲＩ要求が“/index1.html”で始まるのに対して、Ｃｏｏｋｉｅヘッダに記載されているＣｏｏｋｉｅ名“Ｐ”に対応するＣｏｏｋｉｅ値は“/origin”であるため、フィルタ部１１はＷｅｂブラウザ１００からの要求に含まれるＵＲＩがＣｏｏｋｉｅヘッダに記載されているＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分で始まっていないと判定する。そして、Ｃｏｏｋｉｅヘッダに記載されているＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分である“/origin”を、上述のＵＲＩ要求の先頭に挿入する。その結果、フィルタ部１１は、以下の記述（１３）に示すＵＲＩ要求をリバースプロキシ部１２に受け渡す。これにより、リバースプロキシ部１２は、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩが絶対パスで記述されていても、どの機器２００に対してのＵＲＩ要求であるかを知ることが可能となる。
ＧＥＴ /origin/index１.html HTTP/1.1
Ｈｏｓｔ：ｐｒｏｘｙ
Ｃｏｏｋｉｅ：ｐ＝/origin
Ｒｅｆｅｒｅｒ：http://proxy/origin/index.html・・・（１３）

なお、ステップＳ１３〜ステップＳ１６までのリバースプロキシ部１２の処理は、図３で説明したステップＳ４〜ステップＳ７までのリバースプロキシ部１２の処理と同様であるため、説明を省略する。

（第１実施形態の効果について）
機器２００が有しているコンテンツは、通常、ユーザの宅内で閲覧されることを前提として設計されているため、必ずしも外部から参照されることを考慮して設計されているとは限らない。すなわち、コンテンツの保存場所を機器２００固有のディレクトリ構成に基づいて絶対パスで記述されている場合がある。そのため、外出先などからＷｅｂブラウザ１００によって閲覧する際にＷｅｂブラウザ１００からのＵＲＩ要求および機器２００からの応答について、リバースプロキシサーバ１０によって適切に変換してから転送する必要がある。

この第１実施形態におけるリバースプロキシサーバ１０は、インターネット１１０（外部ネットワーク）に属するＷｅｂブラウザ１００（ユーザエージェント）からの要求を受け付けて、Ｗｅｂブラウザ１００の要求先に応じて、ＬＡＮ１２０（内部ネットワーク）に属する複数の機器２００（複数のオリジンサーバ）のいずれかへと要求を中継するものであり、上述の要求には、上述の要求以前にＷｅｂブラウザ１００に対してリバースプロキシサーバ１０のＣｏｏｋｉｅ付与部２２がＳｅｔ−Ｃｏｏｋｉｅヘッダにて指示した情報であるＣｏｏｋｉｅ名およびＣｏｏｋｉｅ値が含まれており、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩと、その要求のＣｏｏｋｉｅヘッダに含まれるＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分とを比較して、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩを書き換えるか否かを判定し、その判定結果に応じてＷｅｂブラウザ１００からの要求に含まれるＵＲＩを書き換えるようにしている。これにより、このリバースプロキシサーバ１０では、仮に絶対パスで記述されているリンクが機器２００のコンテンツに存在していたとしても、Ｃｏｏｋｉｅ付与部２２がＳｅｔ−Ｃｏｏｋｉｅヘッダにて予め指示したＣｏｏｋｉｅ名がＷｅｂブラウザ１００からの要求に含まれるＣｏｏｋｉｅヘッダに記述されている場合には、このＣｏｏｋｉｅヘッダに含まれるＣｏｏｋｉｅ値から導出される仮想パス名の先頭部分をＵＲＩ要求の先頭部分に挿入してからリバースプロキシ部１２に受け渡し、リバースプロキシ部１２においてどの機器２００への要求であるかを判断してから転送することが可能になる。すなわち、このリバースプロキシサーバ１０は、機器２００で保有するコンテンツのリンクが絶対パスで記述されている場合であっても、Ｗｅｂブラウザ１００からのＵＲＩ要求を目的の機器２００に対して転送させることができる。

なお、本実施形態とは異なり、Ｗｅｂページ内に含まれるハイパーリンクが“/”で始まっている場合には置き換えが必要と判断して、その応答の契機となったＨＴＴＰ要求から補完すべき文字列（本実施形態でいえば、“/orijin”に該当するどの機器２００への要求であるのかがわかる文字列）を検索して、ＵＲＩ要求のハイパーリンク文字列の先頭に補完するという方法も考えられるが、このような方法では、Ｗｅｂページ内に含まれるハイパーリンクそのものを書き換える必要がある。たとえば、ＪａｖａＳｃｒｉｐｔなどで動的にハイパーリンクが生成される場合にはさらに細かい制御が必要となる。そのため、動的にハイパーリンクが生成される場合には絶対パスの置き換え判定が非常に困難になる。この点、本実施形態においては、応答の契機となったリンク元のＷｅｂページに含まれる情報を参照して操作するのではなく、リンク先への要求に含まれる情報を参照して操作を行っているため、リンク元のＷｅｂページ内に含まれるハイパーリンクそのものを書き換える必要がない。すなわち、リンク元のＷｅｂページが上述したようなＪａｖａＳｃｒｉｐｔなどで動的にハイパーリンクが生成されるものであっても、これを解釈しないで絶対パスの置き換え判定ができる構成となっている。

[第２実施形態]
図５は、本発明の第２実施形態に係るリバースプロキシサーバ１０Ａの機能的な構成を示すブロック図である。図５に示すリバースプロキシサーバ１０Ａでは、本発明の第１実施形態に係るリバースプロキシサーバ１０とは異なり、Ｃｏｏｋｉｅヘッダを用いるものではなく、Ｒｅｆｅｒｅｒヘッダを用いてＷｅｂブラウザ１００からのＵＲＩ要求を目的の機器２００へと転送させるものである。なお、Ｒｅｆｅｒｅｒヘッダとは、ＨＴＴＰヘッダの１つであり、インターネット上の１つのウェブページまたは１つのリソースからみて、それにリンクしているウェブページやリソースのアドレスが記載されているものである。なお、第１実施形態と同様の機能については、同一の記号を付して、その説明の一部または全部を省略する。

フィルタ部１１Ａは、図５に示すように、判定部２１Ａと、処理部２３と、要求発行部２４と、応答発行部２５、機器情報登録テーブル２６とを有している。

判定部２１Ａは、Ｗｅｂブラウザ１００からのＵＲＩ要求に、Ｒｅｆｅｒｅｒヘッダが含まれているか否かを判定すると共に、Ｒｅｆｅｒｅｒヘッダが含まれていると判定した場合には、このＵＲＩ要求がＲｅｆｅｒｅｒヘッダに記載されているＵＲＩに含まれるパス名で始まるか否かを更に判定して、この判定結果に応じて受け付けたＵＲＩ要求を書き換えるか否かを決定する。

たとえば、判定部２１Ａは、Ｗｅｂブラウザ１００からのＵＲＩ要求に、Ｒｅｆｅｒｅｒヘッダが含まれており、かつこのＵＲＩ要求がＲｅｆｅｒｅｒヘッダに記載されているＵＲＩに含まれるパス名と一致する場合には、このＵＲＩ要求は書き換える必要がないと判断し、後述する要求発行部２４へとそのまま受け渡す。

また、判定部２１Ａは、Ｗｅｂブラウザ１００からのＵＲＩ要求に、Ｒｅｆｅｒｅｒヘッダが含まれており、かつこのＵＲＩ要求がＲｅｆｅｒｅｒヘッダに記載されているＵＲＩに含まれるパス名と一致しない場合には、このＵＲＩ要求は書き換える必要があると判断し、後述する処理部２３に対してＵＲＩ要求の書き換え処理の実行を指示する。

なお、判定部２１Ａは、Ｗｅｂブラウザ１００からのＵＲＩ要求にＲｅｆｅｒｅｒヘッダが含まれていない場合には、Ｗｅｂブラウザを起動してから初めての接続であるか、またはユーザが明示的にＵＲＩを指定していると推測されるため、このＵＲＩ要求をリバースプロキシ部１２へそのまま受け渡す。

機器情報登録テーブル２６には、機器２００の公開パス名とリバースプロキシサーバ１０上の仮想パス名とを適切に書き換えるための関係情報（たとえば上述した転送起点そのものと機器２００との対応関係を示す情報など）が記憶されているテーブルである。リバースプロキシサーバ１０Ａでは、機器情報登録テーブル２６に記憶されている関係情報を参照することにより、ＵＲＩに転送起点が含まれているか否かや、どの機器２００に対してのＵＲＩ要求であるのかを把握して、正しい転送先を決定することができる。なお、フィルタ部１１Ａが有する機器情報登録テーブル２６と、リバースプロキシ部１２が有する機器情報登録テーブル３３とは、機器２００に関する同一の情報を保持しているため、フィルタ部１１Ａおよびリバースプロキシ部１２とは独立したものとして構築してもよいし、いずれか一方に構築しておき、テーブルを保持していない方からテーブルを保持している方へ参照するような構成としてもよい。

なお、処理部２３、要求発行部２４、応答発行部２５およびリバースプロキシ部１２については、上述した第１実施形態と同様の機能を有するものであるため、説明を省略する。

（通信処理）
続いて、リバースプロキシサーバ１０Ａが実行する中継処理について説明する。なお、リバースプロキシサーバ１０Ａでは、Ｗｅｂブラウザ１００からＵＲＩ要求が送信されてくると、Ｒｅｆｅｒｅｒヘッダの有無に応じてその後の処理が異なるため、それぞれ別々のフローチャートを示して説明することとする。図６および図７は、図５に示すリバースプロキシサーバ１０Ａが実行する中継処理の一例を示すフローチャートである。

まず、図６に示すフローチャートを参照してＷｅｂブラウザ１００からのＵＲＩ要求にＲｅｆｅｒｅｒヘッダが含まれていない場合の処理を説明する。この図６に示す中継処理は、たとえば、Ｗｅｂブラウザ１００が起動されてから初めてアクセスする場合に実行される処理手順である。

図６のステップＳ２１において、Ｗｅｂブラウザ１００は、下記の記述（１４）のＵＲＩ要求をリバースプロキシサーバ１０Ａに対して送信する。なお、このＵＲＩ要求にはリバースプロキシサーバ１０Ａを示すホスト情報として“ｐｒｏｘｙ”が設定されている。
ＧＥＴ /origin/index.html HTTP/1.1
Ｈｏｓｔ：ｐｒｏｘｙ ・・・（１４）

ステップＳ２２において、リバースプロキシサーバ１０Ａのフィルタ部１１Ａは、上記の（１４）のＵＲＩ要求を受信すると、このＵＲＩ要求にＲｅｆｅｒｅｒヘッダがあるか否かを判定する。このステップＳ２２において、フィルタ部１１Ａは、ステップＳ２１で送信されたＵＲＩ要求にＲｅｆｅｒｅｒヘッダがないと判定してステップＳ２３に移行する。

ステップＳ２３において、フィルタ部１１Ａは、ステップＳ２１で送信されたＵＲＩ要求については書き換える必要がないため、リバースプロキシ部１２にそのまま受け渡す。

ステップＳ２４において、リバースプロキシ部１２は、ステップＳ２３でフィルタ部１１Ａから受け渡されたＵＲＩ要求を、機器２００のディレクトリ構成にあった形式に変換した下記の記述（１５）に示すＵＲＩ要求を機器２００に対して発行する。具体的には、リバースプロキシサーバ１０Ａ側でどの機器２００であるかを判別する部分（すなわち、上述した第１実施形態で説明した転送起点）である/originを除去したＵＲＩ要求を機器２００に対して発行する。
ＧＥＴ /index.html HTTP/1.1
Ｈｏｓｔ：orijin ・・・（１５）

ステップＳ２５において、機器２００は、ステップＳ２４のＵＲＩ要求に対する応答を発行する。具体的には、“index.html”を構成するデータをリバースプロキシサーバ１０Ａに対して送信する。

ステップＳ２６において、リバースプロキシ部１２は、ステップＳ２５で送信された機器２００からの応答を受信すると、その応答をフィルタ部１１Ａへと受け渡す。

ステップＳ２７において、フィルタ部１１Ａは、ステップＳ２６で受け渡された機器２００からの応答をＷｅｂブラウザ１００へと戻す。下記の記述（１６）に、その一例を示す。
ＨＴＴＰ/１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｘｘｘｘ
Ｃｏｎｎｅｃｔｉｏｎ：ｃｌｏｓｅ・・・（１６）

続いて、図７に示すフローチャートを参照して、Ｗｅｂブラウザ１００からのＵＲＩ要求にＲｅｆｅｒｅｒヘッダが含まれている場合の中継処理について説明する。なお、図７に示す中継処理は、表示されている“index.html”というＷｅｂページ内の“index１.html”というリンクがユーザによりクリックされたものとして説明する。

ステップＳ３０において、Ｗｅｂブラウザ１００は、以下の記述（１７）のＵＲＩ要求をリバースプロキシサーバ１０Ａに対して送信する。なお、このステップＳ３０に示したＵＲＩ要求は、絶対パスで記載されている。また、このステップＳ３０に示したＵＲＩ要求には、リンク元のＵＲＩ情報が記載されたＲｅｆｅｒｅｒヘッダとが含まれている。
ＧＥＴ /index１.html HTTP/1.1
Ｈｏｓｔ：ｐｒｏｘｙ
Ｒｅｆｅｒｅｒ：http://proxy/origin/index.html ・・・（１７）

ステップＳ３１において、リバースプロキシサーバ１０Ａのフィルタ部１１Ａは、ステップＳ３０で送信されたＵＲＩ要求を受信すると、このＵＲＩ要求に判定部２２ＡによりＲｅｆｅｒｅｒヘッダがあるか否かを判定する。ステップＳ３０で説明したように、ステップＳ３０で送信されたＵＲＩ要求にはＲｅｆｅｒｅｒヘッダがあるため、フィルタ部１１Ａは、更にステップＳ３２の判定に移行する。

ステップＳ３２において、フィルタ部１１Ａは、Ｗｅｂブラウザ１００からのＵＲＩ要求（すなわち、ＧＥＴメソッドで始まる部分）がＲｅｆｅｒｅｒヘッダに記載されているＵＲＩの絶対パス部分が転送起点と一致するか否かを判定する。この例では、Ｗｅｂブラウザ１００からのＵＲＩ要求が“/index1.html”であるのに対して、Ｒｅｆｅｒｅｒヘッダに記載されているＵＲＩの絶対パス部分は、“/origin”であるため、フィルタ部１１ＡはＷｅｂブラウザ１００からの要求に含まれるＵＲＩとＲｅｆｅｒｅｒヘッダに記載されているＵＲＩの絶対パス部分とは一致していない（すなわち、両者の転送起点は一致していない）と判定する。そして、ステップＳ３３において、フィルタ部１１Ａは、Ｒｅｆｅｒｅｒヘッダに記載されているＵＲＩの絶対パス部分（すわなち、“/origin”）を、上述のＷｅｂブラウザ１００からの要求に含まれるＵＲＩの先頭に挿入して要求を発行する。その結果、フィルタ部１１Ａは、以下の記述（１８）のＵＲＩ要求をリバースプロキシ部１２に受け渡す。これにより、リバースプロキシ部１２は、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩが絶対パスで記述されていても、どの機器２００に対してのＵＲＩ要求であるかを知ることが可能となる。
ＧＥＴ /origin/index１.html HTTP/1.1
Ｈｏｓｔ：ｐｒｏｘｙ
Ｒｅｆｅｒｅｒ：http://proxy/origin/index.html ・・・（１８）

なお、ステップＳ３４〜ステップＳ３７までのリバースプロキシ部１２の処理は、図３で説明したステップＳ１４〜ステップＳ１７までのリバースプロキシ部１２の処理と同様であるため、説明を省略する。

（第２実施形態の効果について）
この第２実施形態におけるリバースプロキシサーバ１０Ａでは、インターネット１１０（外部ネットワーク）に属するＷｅｂブラウザ１００（ユーザエージェント）からの要求を受け付けて、Ｗｅｂブラウザ１００の要求先に応じて、ＬＡＮ１２０（内部ネットワーク）に属する複数の機器２００（複数のオリジンサーバ）のいずれかへと要求を中継するものであり、上述の要求には、Ｗｅｂブラウザ１００からの要求の直前にＷｅｂブラウザ１００が機器２００への要求を行ったリンク元を示す情報が記述されているＲｅｆｅｒｅｒヘッダが含まれており、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩと、Ｒｅｆｅｒｅｒヘッダに含まれるＵＲＩとを比較して、Ｗｅｂブラウザ１００からの要求に含まれるＵＲＩを書き換えるか否かを判定し、その判定結果に応じてＷｅｂブラウザ１００からの要求に含まれるＵＲＩを書き換えるようにしている。これにより、リバースプロキシサーバ１０Ａは、仮に絶対パスで記述されているリンクが機器２００のコンテンツに存在していたとしても、Ｒｅｆｅｒｅｒヘッダを参照してＷｅｂブラウザ１００の要求直前のＵＲＩを参照することにより、絶対パスで記述されているＵＲＩの先頭部分にリバースプロキシサーバ１０Ａで解釈するためのパス部分を挿入することができる。その結果、リバースプロキシ部１２においてどの機器２００への要求であるかを判断して転送することができる。すなわち、機器２００で保有するコンテンツのリンクが絶対パスで記述されている場合であっても、Ｗｅｂブラウザ１００からのＵＲＩ要求を目的の機器２００に対して転送させることができる。

（その他の実施の形態）
上述した各実施の形態は、その要旨を逸脱しない限り、様々に変更が可能である。たとえば、第１実施形態におけるリバースプロキシサーバ１０の機能と第２実施形態のリバースプロキシサーバ１０Ａの両方の機能を併せ持ち、Ｗｅｂブラウザ１００からの要求の種類に応じて、どちらの機能により判定するかを決定するように構成してもよい。たとえば、Ｗｅｂブラウザ１００からＧＥＴメソッドの要求が送信されてきた場合には、第２実施形態におけるリバースプロキシサーバ１０Ａの機能により、Ｒｅｆｅｒｅｒヘッダの有無に応じてＵＲＩの書き換え判定を行うように構成すると共に、Ｗｅｂブラウザ１００からＰＯＳＴメソッドの要求が送信されてきた場合には、第１実施形態におけるリバースプロキシサーバ１０の機能により、Ｃｏｏｋｉｅヘッダに含まれているＣｏｏｋｉｅ名が一致するか否かを判定するようにしてもよい。このような構成とすることにより、たとえば、Ｒｅｆｅｒｅｒヘッダの有無による判定を採用した場合（すなわち、リバースプロキシサーバ１０Ａが有する機能による判定を採用した場合）に大量のデータを２回アップロードしなければならなくなるという問題を解消することができる。これは、Ｒｅｆｅｒｅｒでは孫参照ができないため、リバースプロキシサーバ１０Ａの応答で「３０１ Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ」などの応答を使って対処したい場合に発生する問題である。リバースプロキシサーバ１０Ａが１回目のＨＴＴＰ要求に対して３０１応答を返すと、Ｗｅｂブラウザ１００は、その３０１応答に含まれるＬｏｃａｔｉｏｎ行で指定された宛先に対して２回目のＨＴＴＰ要求を発行することになる。そして、２回目のＨＴＴＰ要求の宛先からその応答として２００（ＯＫ）応答が返り、Ｗｅｂブラウザ１００の要求は完了する。この動作自体はＰＯＳＴメソッドでもＧＥＴメソッドでも同じであるが、ＧＥＴメソッドは１回の要求で数十からせいぜい数百文字を送信するのに対し、ＰＯＳＴメソッドはより多くの文字を送信することが前提となっているため、Ｗｅｂブラウザ１００がたとえば数百万文字を２回送るということが発生し、送信データ量が非常に多くなってしまうことが考えられる。そこで、ＰＯＳＴメソッドの要求の場合には、Ｃｏｏｋｉｅヘッダに基づく判定を採用し（すなわち、リバースプロキシサーバ１０が有する機能による判定）３０１応答を使用しなくても応答できるようにし、ＰＯＳＴメソッド以外の要求の場合にはＲｅｆｅｒｅｒヘッダの有無による判定とすることで、上述した送信データ量が非常に多くなってしまうという問題を解決することができる。

また、上述した第１実施形態では、リバースプロキシサーバ１０がＷｅｂブラウザ１００への応答ヘッダにＣｏｏｋｉｅ名を付与しているため、機器２００側（オリジンサーバ側）でもＣｏｏｋｉｅを付与する構成の場合には、これらのＣｏｏｋｉｅの間で、名前の衝突が起きないように適切な文字列を選択する必要がある。そのような可能性がある場合には、たとえば、リバースプロキシサーバ１０側で付与するＣｏｏｋｉｅ名、あるいは機器２００側で付与するＣｏｏｋｉｅ名について一意に識別できるようにルールを設けるようにしてもよい。

また、上述した図３に示すフローチャートのステップＳ２において、Ｃｏｏｋｉｅ名を持たない要求ＵＲＩは、通常、この要求以前にリバースプロキシサーバ１０へのアクセスをしていない状況であると考えられるが、このほかにも、Ｃｏｏｋｉｅの有効期限が切れた等でＣｏｏｋｉｅが破棄された後に、ユーザがＷｅｂページ内に表示されているリンクをクリックしたという可能性も考えられる。Ｗｅｂブラウザ１００においてＣｏｏｋｉｅが破棄されている場合、リバースプロキシサーバ１０は、要求ＵＲＩに示される絶対パスで指定されている自己のフォルダの参照を試みるが、典型的には当該リソースが存在しないという４０４エラー（Ｎｏｔ Ｆｏｕｎｄ）が発生する。なお、リバースプロキシサーバ１０に設定されている仮想パスのトップレベル毎にアクセス認証を行っている場合には、４０１エラー（Ｕｎａｕｔｈｒｉｚｅｄ）が発生する。このような場合には、Ｗｅｂブラウザ１００側でもう一度リンク元へのＵＲＩ要求を行うことで、リバースプロキシサーバ１０はＣｏｏｋｉｅ名を有する要求として判定するため、その後に正しいリンク先へのアクセスが可能となる。

また、上述した図３に示すフローチャートのステップＳ３において、リバースプロキシサーバ１０側での仮想パス名と機器２００側の公開パス名が同一の場合、判定が正しくできない可能性がある。たとえば、機器２００に“/foo/img/baz.jpg”というフォルダ構成およびファイルが存在し、そこへ機器２００内の絶対パス指定がなされている場合を想定する。ここで、リバースプロキシサーバ１０では
http://proxy/foo/bar.html
への要求があると
http://origin/bar.html
に転送される場合に、この“bar.html”に
<A HREF=/foo/img/baz.jpg＞
というハイパーリンクがあった場合（ａ）と、
<A HREF=./img/baz.jpg＞
というハイパーリンクがあった場合（ｂ）は、いずれもＷｅｂブラウザ１００からは以下の記述（１９）のような要求が発行されることになる。
ＧＥＴ /foo/img/baz.jpg HTTP/1.1
ＨＯＳＴ ：proxy
Ｃｏｏｋｉｅ：ｐ＝/foo
・・・（１９）
リバースプロキシサーバ１０側では、この要求が上述の（ａ）か（ｂ）のいずれであるかの区別がつかないが、（ａ）は置き換えを発生させるべきであり、（ｂ）は置き換えを発生させるべきではない。このような事象を回避させるためには、リバースプロキシサーバ１０での仮想パス名と機器２００側の公開パス名の衝突が起きないように、仮想パス名には、たとえばＧＵＩＤなどの衝突の可能性が低い文字列を使用することが好ましい。なお、公開パス名についても同様にたとえばＧＵＩＤなどの衝突の可能性が低い文字列を使用することが好ましい。

なお、上述した例での要求ヘッダ行は、ＲＦＣ２６１６、ＲＦＣ２３９６でいう絶対パス（abs_path）形式となっているが、規格上は絶対ＵＲＩ（absoluteＵＲＩ）の可能性もある。即ち、
ＧＥＴ http://proxy/foo/img/baz.jpg HTTP1.1 ・・・（２０）
あるいは
ＧＥＴ http://proxy:80/foo/img/baz.jpg HTTP1.1 ・・・（２１）
などの可能性もあるが、上記の記述（２０）や記述（２１）の場合も（ａ）と（ｂ）の区別ができない点には変わりがない。なお、リバースプロキシサーバ１０の判定において、通常は（ａ）と判定するが、リバースプロキシサーバ１０で仮想パスが有効であった場合には、（ｂ）と判定するようなオプション機能を設けるようにしてもよい。このようオプション機能を具備することで、（ａ）と（ｂ）ともに有効なリソースであっても一方しか参照されないが、どちらを参照するかを選ぶことが可能である。

また、上述した図４に示すフローチャートのステップＳ１２においてＵＲＩ要求で指定されたファイル名が省略されている場合も考えられる。
たとえば、下記の記述（２２）に示すように
ＧＥＴ /dir/ HTTP1.1
ＨＯＳＴ ：proxy
Cookie ：ｐ＝/foo ・・・（２２）
という要求の場合には、リバースプロキシサーバ１０のフィルタ部１１で“/foo/dir”を参照するように書き換えることが好ましい。

また、下記の記述（２３）に示すように
ＧＥＴ / HTTP1.1
ＨＯＳＴ ：proxy
Cookie ：ｐ＝/foo ・・・（２３）
という要求の場合には、リバースプロキシサーバ１０のフィルタ部１１で“/foo/”を参照するように書き換えることが好ましい。

また、ＵＲＩ要求が絶対ＵＲＩ（absoluteＵＲＩ）だった場合、たとえば下記の記述（２４）に示すように、
ＧＥＴ http://proxy/img/baz.jpg HTTP1.1
ＨＯＳＴ ：proxy
Cookie ：ｐ＝/foo ・・・（２４）
という要求の場合には、リバースプロキシサーバ１０のフィルタ部１１で
“http://proxy/foo/img/baz.jpg”を参照するように書き換えることが好ましい。

また、絶対パス（abs_path）部分が空の場合、たとえば下記の記述（２５）に示すように、
ＧＥＴ http://proxy HTTP1.1
ＨＯＳＴ ：proxy
Cookie ：ｐ＝/foo ・・・（２５）
という要求の場合にはリバースプロキシサーバ１０のフィルタ部１１で
“http://proxy/foo”を参照するように書き換えることが好ましい。

また、上述した第２実施形態におけるリバースプロキシサーバ１０Ａでは、Ｒｅｆｅｒｅｒヘッダを解析することで、機器２００への公開パスを得ている。しかしながら、ＲｅｆｅｒｅｒヘッダとしてはＲＦＣ２６１６/ＲＦＣ２３９６でいう絶対ＵＲＩ（abusoluteＵＲＩ）が指定される以外にも、仕様上は相対ＵＲＩ（relativeＵＲＩ）となる可能性もある。たとえば、下記の記述（２６），（２７），（２８）などである。
Ｒｅｆｅｒｅｒ：//proxy/foo/bar.html ・・・（２６）
Ｒｅｆｅｒｅｒ：/foo/bar.html
・・・（２７）
Ｒｅｆｅｒｅｒ：bar.html
・・・（２８）
上記の記述（２６）、（２７）、（２８）のような場合、リバースプロキシサーバ１０Ａは、Ｗｅｂブラウザ１００からの要求ＵＲＩに含まれる他の情報から不足部分を補って判断することが好ましい。

また、上述した第２実施形態におけるリバースプロキシサーバ１０Ａでは、判定が正しくできない可能性がある。たとえば、機器２００の“/bar.html”に“/baz.html”へのハイパーリンクがあり、“/baz.html”に“/img/qux.jpg”へのハイパーリンクがある場合を考える。“/bar.html”を参照したＷｅｂブラウザ１００が“/baz.html”を要求する場合、リバースプロキシサーバ１０ＡへのＵＲＩ要求は以下の記述（２９）となる。
ＧＥＴ /baz.html HTTP1.1
ＨＯＳＴ ：proxy
Refereｒ ：http://proxy/foo/bar.html
・・・（２９）
ここで、リバースプロキシサーバ１０ＡではＷｅｂブラウザ１００からの要求ＵＲＩの書き換えを行うと、以下の記述（３０）となる。
ＧＥＴ /foo/baz.html HTTP1.1
ＨＯＳＴ ：orijin
Refereｒ ：http://proxy/foo/bar.html
・・・（３０）
リバースプロキシサーバ１０Ａは上記の記述（３０）という要求を機器２００へ送信して、“/baz.html”を取得する。そして、その後にＷｅｂブラウザ１００において“/baz.html”に含まれる“/img/qux.jpg”の絶対パスで記載されているハイパーリンクを辿って“qux.jpg”を参照する場合、Ｗｅｂブラウザ１００から以下の記述（３１）の要求が生成される。
ＧＥＴ /img/qux.jpg HTTP1.1
ＨＯＳＴ ：proxy
Refereｒ ：http://proxy/baz.html
・・・（３１）
上記の記述（３１）のＲｅｆｅｒｅｒヘッダに示されるように、“/foo”が含まれていないので、上述した図７のステップＳ３２で説明した判定では、要求ＵＲＩの転送起点に該当するものがなく、この判定を実行する前提としての比較要件が満たされていないため、書き換えが行われなくなってしまう。これは、“/baz.html”の参照に際して、Ｗｅｂブラウザ１００はあくまでも“http://proxy/baz.html”から辿ったと判断しているためである。そのため、リバースプロキシサーバ１０Ａを正しく動作させるためには、Ｗｅｂブラウザ１００に対して、この要求ＵＲＩで指定している“/baz.html”は、実際には“http://proxy/foo/baz.html”にあることを通知しなければならない。

ＨＴＴＰには、このようなＵＲＩが変わった旨をリバースプロキシサーバ１０ＡからＷｅｂブラウザ１００に通知する応答コード（たとえば、３０１（Moved Permanently）、３０２（Found）、３０５（Use Proxy）、３０７（Temporary Redirect）など）が定義されている。ＨＴＴＰのバージョンやＷｅｂブラウザ１００によりどの応答コードで対応可能であるかについて差異があるため、要求元のＨＴＴＰバージョンやＵｓｅｒＡｇｅｎｔ行を見てどの応答コードを返すのかについて適宜分岐して応答を返すように設定する必要がある。なお、いずれの応答コードの場合も応答ヘッダのＬｏｃａｔｉｏｎ行に変更後のＵＲＩを記載する。たとえば、以下の記述（３２）に示すような応答ヘッダを生成する。
HTTP/1.1 307 Temporary Redirect
Date：Fri，18 May 2012 01:05:07 GMT
Location:http://proxy/foo/img/baz.jpg
Connection：Close
・・・（３２）

また、上述した実施の形態で説明したリバースプロキシサーバ１０，１０Ａ及びこれらの変形例において実行される処理のすべてまたは一部をプログラムによって構成し、これらのプログラムを実行可能な状態で記録した媒体からコンピュータに直接インストールする、またはネットワーク経由で遠隔にあるコンピュータにインストールすることもできる。

図８は、図１および図５で説明したリバースプロキシサーバ１０，１０Ａのハードウェア構成の一例を示す図である。上述したリバースプロキシサーバ１０，１０Ａ及びこれらの変形例で構成されるコンピュータでは、ＣＰＵ３０１が、たとえば、記憶部３０８に記憶されている中継プログラムを、入出力インタフェース３０４およびバス３０５を介して、ＲＡＭ１０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ（ＣＰＵ３０１）が実行する中継プログラムは、たとえば、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ＲＯＭ(Compact Disc-Read Only
Memory),DVD(Digital Versatile Disc)等）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア３１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。

そして、中継プログラムは、リムーバブルメディア３１１をドライブ３１０に装着することにより、入出力インタフェース３０４を介して、記憶部３０８にインストールすることができる。また、中継プログラムは、有線または無線の伝送媒体を介して、通信部３０９で受信し、記憶部３０８にインストールすることができる。その他、プログラムは、ＲＯＭ３０２や記憶部３０８に、あらかじめインストールしておくことができる。

なお、コンピュータが実行する中継プログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。さらに、中継プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。また、中継プログラムを実行するハードウェアとして、汎用コンピュータの他に、上述したリバースプロキシサーバ１０，１０Ａ及びこれらの変形例の機能を備えているものであれば、他の電子機器上に構成されるものであってもよい。

１０，１０Ａ…リバースプロキシサーバ（中継装置の一例）、１１，１１Ａ…フィルタ部、１２…リバースプロキシ部、２１，２１Ａ…判定部、２２…Ｃｏｏｋｉｅ付与部、２３…処理部、２４…要求発行部、２５…応答発行部、２６…機器情報登録テーブル、３１…要求発行転送部、３２…応答発行転送部、３３…機器情報登録テーブル、１００…Ｗｅｂブラウザ（ユーザエージェントの一例）、１１０…インターネット、２００，２００Ａ，２００Ｂ，２０００Ｃ…機器（オリジンサーバの一例）

Claims (6)

1. 外部ネットワークに属するユーザエージェントからの要求を受け付けて、前記ユーザエージェントの要求先に応じて、内部ネットワークに属する複数のオリジンサーバのいずれかへと前記要求を中継する中継装置であって、
   前記要求には、前記ユーザエージェントに対して前記中継装置が予め付与した情報が記述されているヘッダ、あるいは前記ユーザエージェントが前記オリジンサーバへの要求を行ったリンク元を示す情報が記述されているヘッダが含まれており、
   前記ユーザエージェントからの要求に含まれるＵＲＩと、前記ヘッダに含まれるＵＲＩとを比較して、前記ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定する判定部と、
   前記判定部の判定結果に応じて前記ユーザエージェントからの要求に含まれるＵＲＩを書き換える処理部と、
   を有することを特徴とする中継装置。
   
2. 請求項１に記載の中継装置であって、
   前記判定部は、
   前記ユーザエージェントから送信される要求の種類に応じて、前記要求以前に前記ユーザエージェントに対して前記中継装置が予め付与した情報が記述されているヘッダ、および前記要求の直前に前記ユーザエージェントが要求を行ったリンク元を示す情報が記述されているヘッダのいずれかを参照して、前記ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定することを特徴とする中継装置。
   
3. 請求項１または２に記載の中継装置であって、
   前記ユーザエージェントからの要求に前記中継装置が予め付与した情報が記述されているヘッダがないときは、前記要求の応答を前記ユーザエージェントに送信する際に、Ｓｅｔ−Ｃｏｏｋｉｅヘッダを付与するヘッダ付与部を有し、
   前記処理部は、
   前記ユーザエージェントから、前記ヘッダ付与部により付与されたＳｅｔ−Ｃｏｏｋｉｅヘッダにて指定したＣｏｏｋｉｅ名が含まれているＣｏｏｋｉｅヘッダを有する要求があった場合に、その要求に含まれるＵＲＩの記述が、その要求のＣｏｏｋｉｅヘッダに含まれるＣｏｏｋｉｅ名に対応するＣｏｏｋｉｅ値の記述で始まっていない場合には、前記ユーザエージェントからの要求に含まれるＵＲＩの書き換えを行うことを特徴とする中継装置。
   
4. 請求項１から３のいずれか1項に記載の中継装置であって、
   前記判定部は、
   前記ユーザエージェントからの要求の直前に前記ユーザエージェントが前記オリジンサーバへの要求を行ったリンク元を示す情報が記述されているＲｅｆｅｒｅｒヘッダを参照し、前記ユーザエージェントからの要求に含まれるＵＲＩと、前記Ｒｅｆｅｒｅｒヘッダに含まれるＵＲＩの一部とを比較して、両者が一致しない場合に前記ユーザエージェントからの要求に含まれるＵＲＩの書き換えを行うことを特徴とする中継装置。
   
5. 外部ネットワークに属するユーザエージェントからの要求を受け付けて、前記ユーザエージェントの要求先に応じて、内部ネットワークに属する複数のオリジンサーバのいずれかへと前記要求を中継する中継装置が実行する中継方法であって、
   前記要求には、前記ユーザエージェントに対して前記中継装置が予め付与した情報が記述されているヘッダ、あるいは前記ユーザエージェントが前記オリジンサーバへの要求を行ったリンク元を示す情報が記述されているヘッダが含まれており、
   前記ユーザエージェントからの要求に含まれるＵＲＩと、前記ヘッダに含まれるＵＲＩとを比較して、前記ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定する判定ステップと、
   前記判定ステップの判定結果に応じて前記ユーザエージェントからの要求に含まれるＵＲＩを書き換える処理ステップと、
   を有することを特徴とする中継方法。
6. コンピュータを、外部ネットワークに属するユーザエージェントからの要求を受け付けて、前記ユーザエージェントの要求先に応じて、内部ネットワークに属する複数のオリジンサーバのいずれかへと前記要求を中継する中継装置として機能させるためのプログラムであって、
   前記要求には、前記ユーザエージェントに対して前記中継装置が予め付与した情報が記述されているヘッダ、あるいは前記ユーザエージェントが前記オリジンサーバへの要求を行ったリンク元を示す情報が記述されているヘッダが含まれており、
   前記コンピュータを、
   前記ユーザエージェントからの要求に含まれるＵＲＩと、前記ヘッダに含まれるＵＲＩとを比較して、前記ユーザエージェントからの要求に含まれるＵＲＩを書き換えるか否かを判定する判定手段と、
   前記判定手段の判定結果に応じて前記ユーザエージェントからの要求に含まれるＵＲＩを書き換える処理手段と、
   として機能させるための中継プログラム。
   

Images