JP5500020B2 - Ｗｅｂアプリケーション提供方法、中継サーバ装置、Ｗｅｂサーバ装置 - Google Patents

Description

本発明は、Ｗｅｂアプリケーションを提供する方法、装置、プログラム、並びにＷｅｂアプリケーションを中継する方法、装置、プログラムに係わる。

インターネットが普及し、ユーザは、ブラウザを利用してＷｅｂサーバが提供する情報を閲覧することができる。また、ユーザは、Ｗｅｂサーバが提供するアプリケーションプログラムを利用することができる。この場合、ユーザは、例えば、Ｗｅｂアプリケーションサーバへデータを送信する。そうすると、Ｗｅｂアプリケーションサーバは、受信したデータに対して演算を実行し、その結果をクライアント（ユーザの端末）へ返送する。

近年では、ユーザは、しばしば、より利便性の高いサービスを要求する。しかし、この要求に答えるためは、ユーザ毎に様々な機能を用意する必要がある。このため、多数のユーザにサービスを提供するＷｅｂサーバ側で上述の要求に対処することは容易ではない。一方、ブラウザ側で上述のサービスを実現するためには、ユーザは、特殊な機能を備える専用のブラウザを用意する必要がある。このため、ブラウザとＷｅｂサーバとの間に中継サーバを配置し、中継サーバが各種サービスを付加する構成が提案されている。

図１は、中継サーバがサービスを付加する方法を説明する図である。ここでは、クライアント１とＷｅｂサーバ３との間に中継サーバ２が配置されている。また、クライアント１は、Ｗｅｂブラウザを備えている。

図１（ａ）に示す例では、Ｗｅｂブラウザは、ユーザの指示に応じて、Ｗｅｂページを閲覧するためのリクエストを送信する。このリクエストは、いったん中継サーバ２により受信される。そして、中継サーバ２は、このリクエストをＷｅｂサーバ３へ送信する。

Ｗｅｂサーバ３は、受信したリクエストに従ってＷｅｂページを生成して中継サーバ２へ送信する。ここで、Ｗｅｂサーバ３が提供するＷｅｂページのテキストは、英語で記述されているものとする。また、中継サーバ２には、自動翻訳プログラムが実装されている。そして、中継サーバ２は、Ｗｅｂサーバ３から受信したＷｅｂページのテキストを英語から日本語に翻訳する。その後、中継サーバ２は、翻訳後のＷｅｂページをクライアント１へ送信する。この結果、クライアント１のＷｅｂブラウザには、日本語に翻訳されたＷｅｂページが表示される。

図１（ｂ）に示す例では、Ｗｅｂブラウザは、データ処理を依頼するためのリクエストを送信する。このリクエストは、図１（ａ）に示す手順と同様に、中継サーバ２を経由してＷｅｂサーバ３へ転送される。

Ｗｅｂサーバ３は、受信したリクエストに従ってＷｅｂアプリケーションプログラムを実行し、処理結果を含むリプライを中継サーバ２へ送信する。中継サーバ２は、Ｗｅｂサーバ３から受信したリプライに、前もってユーザから要求されている機能を実現するためのプログラムコードを挿入する。そして、中継サーバ２は、プログラムコードを含むリプライをクライアント１へ送信する。そうすると、クライアント１において、中継サーバ２によりリプライに挿入されたプログラムコードが実行される。この構成により、Ｗｅｂアプリケーションを変更することなく、ユーザが要求する機能が実現される。図１（ｂ）に示す例では、中継サーバ２により提供されたプログラムコードは、Ｗｅｂサーバ４にアクセスしている。そして、Ｗｅｂブラウザ上で、Ｗｅｂサーバ３が提供するＷｅｂアプリケーションおよびＷｅｂサーバ４が提供するＷｅｂアプリケーションが連携して動作している。

関連する技術として、Ｗｅｂ情報を中継する方法が提案されている。この方法においては、中継サーバは、クライアントからのリクエストを受信し、そのリクエストに対応するウェブページを編集する際に、目的サーバが有するマッシュアップ対象のページに記述されたＵＲＬ情報を抽出する。そして、抽出されたＵＲＬ情報のホスト名のドットを別の文字に置換するとともに、中継サーバのホスト名を付加し、編集後のウェブページをクライアントへ送信する。（例えば、特許文献１）
他の関連する技術として、元サーバのＷｅｂページを中継サーバを介してクライアント端末に転送するシステムが提案されている。このシステムにおいては、クライアント端末は、元サーバのページ情報と書換プログラムを中継サーバから受信し、書換プログラムを実行することでそのページ情報を書き換える。次に、ページ情報の記述に基づき元サーバへのリクエストを生成し、ページ情報の書換情報に従って、そのリクエストに含まれるＵＲＬ情報中の元サーバのサーバ名を中継サーバのサーバ名に変更する。そして、変更後のユニフォームリソースロケータ情報に基づいてリクエストを中継サーバに送信する。

さらに他の関連する技術として、アプリケーション連携のためのＷｅｂアプリケーション編集方法が提案されている。この方法においては、連携対象ＷｅｂアプリケーションのＷｅｂページの一部を切り出して、クライアントのブラウザに表示する場合、制御ロジックを含む連携対象ＷｅｂアプリケーションのＷｅｂページの１ページ分すべてをクライアントブラウザにダウンロードする。そのとき、同時に、Ｗｅｂページのどの部分を切り出すかの情報と、Ｗｅｂページの要素の表示・非表示を制御するコントロール部もダウンロードする。コントロール部は、Ｗｅｂページの切り出したい部分のみを表示させ、他を非表示とする。

特開２００９−２７１６７６号公報 特開２００９−２８９２０６号公報 特開２００９−２２３５５５号公報

上述のように、Ｗｅｂブラウザは、Ｗｅｂサーバ３から中継サーバ２を介して受信するＷｅｂページを閲覧することができる。このとき、Ｗｅｂページの中に、別のページ（以下、関連ページ）へのリンク（例えば、ＵＲＬ）が埋め込まれていることがある。この場合、ユーザは、Ｗｅｂブラウザ上でこのリンクを指定すれば、関連ページを閲覧できる。

図２に示す例では、クライアント１のＷｅｂブラウザは、Ｗｅｂサーバ３から取得したＷｅｂページ（example.com/app1/page3）を表示している。このＷｅｂページには、前ページ（example.com/app1/page2）及び次ページ（example.com/app1/page4）へのリンクが埋め込まれている。この場合、ユーザが、たとえば「次ページ」を指定すれば、Ｗｅｂブラウザ上に「次ページ」の内容が表示される。

ところで、ユーザは、Ｗｅｂサーバ３が提供するＷｅｂページを、中継サーバ２を経由して取得するときは、例えば、Ｗｅｂサーバ３のＵＲＬではなく、中継サーバ２を経由してＷｅｂサーバ３へアクセスするために特殊な加工を施したＵＲＬを指定する。例えば、図２において、中継サーバ２を経由してＷｅｂページ「example.com/app1/page3」を取得するためには、ユーザは、「http://example.com/app1/page3.html」ではなく、「http://http-example-com.proxy.com/app1/page3.html」を指定する。

このため、Ｗｅｂブラウザ上のＷｅｂページに埋め込まれているリンク（図２では、例えば「次ページ」）がユーザにより指定されると、Ｗｅｂブラウザから送信されるリクエストは、中継サーバ２を経由することなく目的サーバへ送信される。この場合、目的サーバから送信される「次ページ」の内容は、中継サーバ２を経由することなくＷｅｂブラウザへ転送される。この結果、「次ページ」については、中継サーバ２によるサービスが付加されない。例えば、図１（ａ）に示す例では、「次ページ」は、翻訳されることなくＷｅｂブラウザに表示されることになる。

このように、従来技術においては、Ｗｅｂサーバから取得する内容の中にリンク先情報が埋め込まれている場合、ユーザは、そのリンク先から取得する内容について中継サーバによる付加的なサービスを受けられないことがある。

上述の問題に対処するためには、例えば、以下の方法が考えられる。すなわち、中継サーバ２が、Ｗｅｂサーバ３からクライアント１へ提供されるＷｅｂページのＨＴＭＬ文書を解釈し、そのＨＴＭＬ文書内のリンク情報を適切に書き換えるようにしてもよい。しかし、この方法では、中継サーバ２は、各リプライのＨＴＭＬ文書を解釈する必要があるので、中継サーバ２の負荷が重くなってしまう。特に、中継サーバ２が多くのユーザにより共有される環境では、中継サーバ２の負荷が重くなると、中継サーバ２が提供するサービスの質が低下するおそれがある。また、中継サーバ２が、ＨＴＭＬ文書を解釈することなく、文字列パターンの照合によってリンク情報を書き換える方法では、リンク先として記述されているＵＲＬだけでなく、データとして記述されているＵＲＬも書き換えられてしまうおそれがある。

また、図２を参照しながら説明した問題に対処するために、以下の方法も考えられる。すなわち、中継サーバ２は、リンク先を呼び出す処理を変更するためのスクリプトコードを、クライアント１へ送信するＨＴＭＬ文書に追加する。この方式であれば、中継サーバ２の負荷は軽い。しかし、この方式では、Ｗｅｂブラウザが上記スクリプトコードをサポートしていないときは、クライアント１は、中継サーバ２を経由するＵＲＬを生成できない。すなわち、クライアント１は、上記スクリプトコードをサポートするＷｅｂブラウザを実装する必要がある。

本発明の課題は、Ｗｅｂサーバからクライアントへ送信されるリプライに中継サーバがサービスを付加するシステムにおいて、中継サーバの負担を重くすることなく、クライアントが中継サーバの提供するサービスを受けられるようにすることである。

本発明の１つの態様のＷｅｂアプリケーション提供方法は、Ｗｅｂサーバから中継サーバを介してクライアントへＷｅｂアプリケーションを提供する方法であって、前記中継サーバは、前記クライアントから受信するリクエストに、前記Ｗｅｂサーバが提供するＷｅｂページ中に設定されているＵＲＬへのアクセスが前記中継サーバを経由するように、前記ＵＲＬを書き換えるための置換情報を追加し、前記中継サーバは、前記置換情報を含むリクエストを前記Ｗｅｂサーバへ送信し、前記Ｗｅｂサーバは、前記リクエストに従って応答Ｗｅｂページを生成し、前記Ｗｅｂサーバは、前記応答Ｗｅｂページ中に設定されるＵＲＬを前記置換情報に基づいて書き換え、前記Ｗｅｂサーバは、前記置換情報に基づいて書き換えられたＵＲＬを含む前記応答Ｗｅｂページを前記中継サーバへ送信し、前記中継サーバは、前記応答Ｗｅｂページを前記クライアントへ送信する。

本発明の１つの態様のプログラムは、クライアントとＷｅｂサーバとの間に配置される中継サーバに、前記クライアントから受信するリクエストに、前記Ｗｅｂサーバが提供するＷｅｂページ中に設定されるＵＲＬへのアクセスが前記中継サーバを経由するように、前記ＵＲＬを書き換えるための置換情報を追加し、前記置換情報を含むリクエストを前記Ｗｅｂサーバへ送信し、前記Ｗｅｂサーバにおいて前記リクエストに応じて生成されたＷｅｂページを含むリプライを前記Ｗｅｂサーバから受信し、前記リプライを前記クライアントへ送信する、処理を実行させる。

本発明の他の態様のプログラムは、Ｗｅｂサーバに、クライアントから送信され、中継サーバにおいて置換情報が追加されたリクエストを受信し、前記リクエストに従ってＷｅｂページを生成し、前記Ｗｅｂページ中に設定されるＵＲＬを、前記置換情報に基づいて、前記ＵＲＬへのアクセスが前記中継サーバを経由するように書き換え、前記置換情報に基づいて書き換えられたＵＲＬを含む前記Ｗｅｂページを前記中継サーバへ送信する、処理を実行させる。

本出願において開示される構成または方法によれば、Ｗｅｂサーバからクライアントへ送信されるリプライに中継サーバがサービスを付加するシステムにおいて、中継サーバの負担を重くすることなく、クライアントは中継サーバの提供するサービスを受けることができる。

中継サーバがサービスを提供する方法を説明する図である。 従来技術の問題点を説明する図である。 実施形態のＷｅｂアプリケーション提供方法の概要を説明する図である。 実施形態の中継サーバの構成を示す図である。 実施形態のＷｅｂサーバの構成を示す図である。 ブラウザから送信されるリクエストの実施例である。 リクエストに置換情報を追加する処理を示すフローチャートである。 置換情報が追加されたリクエストの実施例である。 置換情報抽出部の処理を示すフローチャートである。 ＵＲＬエンコード部が保持するエンコード情報の実施例である。 ページ記述情報の実施例である。 タグ処理部の処理を示すフローチャートである。 タグ処理部によるＵＲＬの置換処理の実施例である。 ＵＲＬエンコード部の処理を示すフローチャートである。 ＵＲＬエンコード部によるエンコード処理の実施例である。 ページ生成部により生成されるＷｅｂページの実施例である。 Ｗｅｂサーバから送信されるリプライの実施例（ＵＲＬエンコード処理あり）である。 Ｗｅｂサーバから送信されるリプライの実施例（ＵＲＬエンコード処理なし）である。 リプライを受信した中継サーバの処理を示すフローチャートである。 中継サーバからクライアントへ送信されるリプライの実施例である。 他の実施形態においてリプライを受信した中継サーバの処理を示すフローチャートである。 中継サーバおよびＷｅｂサーバのハードウェア構成を示す図である。

図３は、実施形態のＷｅｂアプリケーション提供方法の概要を説明する図である。ここでは、クライアント１とＷｅｂサーバ３０との間に中継サーバ１０が配置されている。なお、クライアント１は、Ｗｅｂブラウザを備えている。また、Ｗｅｂサーバ３０は、クライアント１のアクセス先である目的サーバであり、ＷｅｂアプリケーションまたはＷｅｂページを提供する。

クライアント１は、ネットワークを介して中継サーバ１０に接続される。このネットワークは、例えばＬＡＮである。ただし、クライアント１は、他の形態のネットワークで中継サーバ１０に接続するようにしてもよい。また、中継サーバ１０およびＷｅｂサーバ３０は、ネットワークを介して接続される。このネットワークは、例えばインターネットである。ただし、中継サーバ１０およびＷｅｂサーバ３０は、他の形態のネットワークで互いに接続してもよい。なお、クライアント１と中継サーバ１０との間の回線、および中継サーバ１０とＷｅｂサーバ３０との間の回線は、無線リンクで実現してもよいし、有線リンクで実現してもよいし、無線リンクおよび有線リンクが混在してもよい。

クライアント１は、ユーザの指示を受け付けるためのユーザインタフェースを備える。また、クライアント１は、ネットワーク上のＷｅｂページを閲覧するＷｅｂブラウザを備える。Ｗｅｂページは、Ｗｅｂ上にある文書であり、例えば、ＨＴＭＬ文書、スタイルシート、画像データ等を含んでいる。そして、クライアント１は、ユーザにより指定される目的サーバにリクエストを送信することにより、対応するＷｅｂアプリケーションのＷｅｂページを受け取る。すなわち、ユーザは、クライアント１に実装されているＷｅｂブラウザを通して、Ｗｅｂアプリケーションを利用することができる。

上記構成のネットワークシステムにおいて、ユーザは、まず、クライアント１のＷｅｂブラウザを利用して、Ｗｅｂサーバ３０にアクセスするためのリクエストを中継サーバ１０へ送信する。中継サーバ１０は、クライアント１から受信したリクエストのリクエストヘッダに置換情報を追加する。置換情報は、Ｗｅｂサーバ３０が提供するＷｅｂページ中に設定されているＵＲＬへのアクセスが中継サーバ１０を経由するようにそのＵＲＬを書き換えるための指示を含んでいる。そして、中継サーバ１０は、置換情報が追加されたリクエストをＷｅｂサーバ３０へ送信する。

リクエストを受信したＷｅｂサーバ３０は、リクエストヘッダに置換情報が含まれているか否かをチェックする。そして、リクエストヘッダが置換情報を含んでいるときは、Ｗｅｂサーバ３０は、その置換情報を保持しておく。また、Ｗｅｂサーバ３０は、受信したリクエストに従って対応するＷｅｂページを生成する。このＷｅｂページがリンクを含む場合、Ｗｅｂサーバ３０は、そのリンク先を表すＵＲＬを生成してＷｅｂページに埋め込む。このとき、Ｗｅｂサーバ３０は、中継サーバ１０により追加された置換情報に基づいて、リンク先へのアクセスが中継サーバ１０を経由するようにＵＲＬを生成する。一実施例としては、Ｗｅｂサーバ３０は、リンク先を直接的に指し示すＵＲＬを、置換情報に基づいて、中継サーバ１０を経由してリンク先にアクセスするためのＵＲＬに書き換える。以下、この書き換え処理を「エンコード」と呼ぶことがある。さらに、Ｗｅｂサーバ３０は、上述のリクエストに対するＷｅｂページを含むリプライに、ＵＲＬのエンコードを実行したことを表す完了報告情報を追加する。このとき、完了報告情報は、例えば、リプライヘッダに追加される。そして、Ｗｅｂサーバ３０は、中継サーバ１０へリプライを送信する。

中継サーバ１０は、Ｗｅｂサーバ３０からリプライを受信すると、リプライヘッダが完了報告情報を含んでいるか否かをチェックする。そして、リプライが完了報告情報を含むときは、中継サーバ１０は、リプライとして提供されるＷｅｂページにリンク先として埋め込まれているＵＲＬを書き換える処理を実行しない。一方、リプライが完了報告情報を含んでいなければ、中継サーバ１０は、Ｗｅｂページに埋め込まれているＵＲＬを、リンク先へのアクセスが中継サーバ１０を経由するＵＲＬに書き換える。そして、中継サーバ１０は、必要に応じてそのリプライに対してサービスを付加した後、そのリプライをクライアント１へ送信する。

クライアント１のＷｅｂブラウザは、上述のようにしてＷｅｂサーバ３０から中継サーバ１０を経由して送信されるＷｅｂページを表示する。このとき、Ｗｅｂページに埋め込まれているＵＲＬは、Ｗｅｂサーバ３０（または、中継サーバ１０）において、中継サーバ１０を経由してリンク先にアクセスが行われるようにエンコードされている。よって、ユーザがＷｅｂブラウザを利用してこのＵＲＬを指定すると、対応する新たなＷｅｂページは、中継サーバ１０を経由してクライアント１に提供される。したがって、クライアント１は、この新たなＷｅｂページについても、中継サーバ１０が提供するサービスを受けることができる。

また、実施形態のＷｅｂアプリケーション提供方法によれば、Ｗｅｂサーバ３０が実施形態に係わるＵＲＬエンコード方式をサポートしていれば、中継サーバ１０は、Ｗｅｂサーバ３０からのリプライ中のＨＴＭＬ文書を解析しなくてもよい。したがって、中継サーバ１０の負担は軽くなる。この場合、Ｗｅｂサーバ３０は、後で詳しく説明するが、Ｗｅｂページを生成する際に、そのＷｅｂページに設定するリンク先を表す文字列を加工するだけでエンコード処理を実現する。したがって、Ｗｅｂサーバ３０によるＵＲＬエンコードは、ＨＴＭＬ文書全体を解析してそのＨＴＭＬ文書中に埋め込まれているリンク先情報を書き換える手順と比較して、処理量が少ない。よって、ＵＲＬエンコードに起因するＷｅｂサーバ３０の負担の増加量は小さい。

さらに、Ｗｅｂサーバ３０は、Ｗｅｂページを生成する際に、そのＷｅｂページに設定するリンクのみを抽出してエンコードを行う。このため、実施形態の方法によれば、ＨＴＭＬ文書中に記述されている、リンク先ではないＵＲＬ情報が誤って書き換えられることはなく、必要なＵＲＬのみを確実に書き換えることができる。

さらに、実施形態の方法においては、Ｗｅｂページ中のＵＲＬはＷｅｂサーバ３０（または、中継サーバ１０）において書き換えられるので、クライアント１のＷｅｂブラウザは、ＵＲＬを書き換えるためのスクリプトを実行する必要はない。したがって、上記スクリプトをサポートしていないＷｅｂブラウザを実装するクライアント１であっても、中継サーバ１０が提供するサービスを受けることができる。

なお、Ｗｅｂサーバ３０が実施形態のＵＲＬエンコード機能を備えていないときは、Ｗｅｂサーバ３０から中継サーバ１０へ送信されるリプライは、完了報告情報を含まない。すなわち、中継サーバ１０は、リプライヘッダを参照すれば、Ｗｅｂサーバ３０においてＵＲＬエンコード処理が実行されたか否かを認識できる。したがって、中継サーバ１０がＵＲＬを書き換える機能を備えている場合には、Ｗｅｂサーバ３０においてＵＲＬエンコードを行う方式と、中継サーバ１０においてＵＲＬを書き換える方式を併用することが可能である。

図４は、実施形態の中継サーバ１０の構成を示す図である。中継サーバ１０は、要求受付部１１、セッション管理部１２、サブドメイン解釈部１３、置換情報追加部１４、要求転送部１５、応答受付部１６、応答解釈部１７、ＵＲＬ書換え部１８、応答変換部１９、応答転送部２０、ユーザ情報データベース（ＤＢ）２１を備える。

要求受付部１１は、クライアント１のＷｅｂブラウザから送信されるリクエストデータを受信する。また、要求受付部１１は、セッション管理部１２に問合わせを行うことにより、リクエストデータの送信元のユーザＩＤを特定する。このとき、要求受付部１１は、必要に応じてユーザ認証を実行する。認証処理は、特に限定されるものではないが、例えば、CookieまたはＩＰアドレスを利用する方式により実現される。なお、セッション管理部１２は、ユーザ情報ＤＢ２１を参照しながら各クライアントセッションを管理する。

サブドメイン解釈部１３は、要求受付部１１が受け付けたリクエストデータの宛て先ＵＲＬをデコードして目的サーバのＵＲＬを取得する。目的サーバは、この例では、Ｗｅｂサーバ３０である。なお、クライアント１から送信されるリクエストの宛て先ＵＲＬは、中継サーバ１０を経由してＷｅｂサーバ３０へアクセスするように作成されているものとする。

置換情報追加部１４は、リクエストデータのヘッダ部（すなわち、リクエストヘッダ）に、置換情報を追加する。置換情報は、Ｗｅｂページに埋め込まれているＵＲＬへのアクセスが中継サーバ１０を経由するようにそのＵＲＬを書き換えるための指示を含む。具体的には、置換情報は、ＵＲＬのエンコード方式を表す方式情報、およびＵＲＬのエンコード処理において使用される文字列パターンを含む。なお、置換情報追加部１４は、発明に係る追加部の１つの実施例である。

要求転送部１５は、サブドメイン解釈部１３から目的サーバのＵＲＬを受け取り、置換情報追加部１４から置換情報が追加されたリクエストデータを受け取る。そして、要求転送部１５は、置換情報を含むリクエストデータを目的サーバへ送信する。なお、目的サーバ（ここでは、Ｗｅｂサーバ３０）は、中継サーバ１０からリクエストデータを受信すると、対応するリプライデータを生成して中継サーバ１０へ送信する。

応答受付部１６は、目的サーバから送信されるリプライデータを受信する。応答解釈部１７は、応答受付部１６により受信されたリプライデータのヘッダ部（すなわち、リプライヘッダ）を解釈し、中継サーバ１０においてＵＲＬを書き換えるか否かを判定する。また、応答解釈部１７は、セッション管理部１２を参照し、応答変換処理を実行するか否かを判定する。なお、応答解釈部１７は、発明に係る判定部の１つの実施例である。

ＵＲＬ書換え部１８は、応答解釈部１７によりＵＲＬの書換えが必要と判定されたときに、リプライデータのＨＴＭＬ文書内にリンク先として記述されているＵＲＬを書き換える。このとき、ＵＲＬ書換え部１８は、リプライデータから抽出されるＵＲＬを、中継サーバ１０を経由するアクセスを実現するためのＵＲＬに書き換える。

応答変換部１９は、応答変換が必要であると応答解釈部１７により判定されたときに、リプライデータを加工する。このとき、応答変換部１９は、セッション管理部１２を参照して、クライアント１のユーザが要求するサービスを識別する。そして、応答変換部１９は、クライアント１のユーザが要求するサービスに応じてリプライデータを加工する。例えば、ユーザが翻訳サービスを要求しているときは、応答変換部１９は、リプライデータ中のテキストを翻訳する。或いは、応答変換部１９は、ユーザが要求する機能を実現するためのスクリプトコードをリプライデータに挿入する。

応答転送部２０は、リプライデータをクライアント１のＷｅｂブラウザに送信する。このとき、リプライデータ中でリンク先として設定されているＵＲＬは、Ｗｅｂサーバ３０（或いは、ＵＲＬ書換え部１８）により書き換えられている。また、このリプライデータは、応答変換部１９によって加工されていることがある。

ユーザ情報ＤＢ２１は、中継サーバ１０を利用するユーザの情報を格納する。即ち、ユーザ情報ＤＢ２１は、例えば、各ユーザのユーザＩＤおよびパスワードの組を格納する。また、ユーザ情報ＤＢ２１は、各ユーザが中継サーバ１０に要求するサービスの種別を表す情報を格納する。

図５は、実施形態のＷｅｂサーバ３０の構成を示す図である。Ｗｅｂサーバ３０は、要求受付部３１、置換情報抽出部３２、ページ生成部３３、ページ記述情報格納部３４、アプリケーション処理部３５、タグ処理部３６、ＵＲＬエンコード部３７、応答送信部３８を備える。

要求受付部３１は、クライアント１のＷｅｂブラウザまたは中継サーバ１０から送信されるリクエストデータを受信する。また、要求受付部３１は、リクエストデータの送信元のユーザＩＤを特定する。このとき、要求受付部３１は、必要に応じてユーザ認証を実行する。認証処理は、特に限定されるものではないが、例えば、中継サーバ１０と同様の方式を採用してもよい。

置換情報抽出部３２は、リクエストデータのヘッダ部（すなわち、リクエストヘッダ）に、置換情報が付加されているか否かをチェックする。リクエストヘッダに置換情報が付加されているときは、置換情報抽出部３２は、リクエストヘッダから置換情報を抽出してＵＲＬエンコード部３７に与える。また、置換情報抽出部３２は、リクエストヘッダからさらにプロトコル名、ホスト名、パス名を抽出してＵＲＬエンコード部３７に与える。そして置換情報抽出部３２は、リクエストデータと共に、このリクエストデータの送信元のユーザＩＤ等をページ生成部３３へ送信する。

ページ生成部３３は、Ｗｅｂアプリケーションのフレームワークを利用して、リクエストデータに応じたＷｅｂページを生成する。この実施例では、ページ生成部３３は、例えばStrutsと呼ばれるフレームワークを利用してＷｅｂページを生成する。すなわち、ページ生成部３３は、ページ記述情報格納部３４から、リクエストデータに含まれているパス名に対応するページ記述情報を取得する。そして、ページ生成部３３は、取得したページ記述情報に応じてアプリケーション処理部３５を呼び出す。ここで、Strutsフレームワークでは、ページ記述情報内のＨＴＭＬ要素を生成する部分は、カスタムタグを用いて記述されている。このため、ページ生成部３３は、StrutsのカスタムタグをＨＴＭＬに展開するために、タグ処理部３６を呼び出す。そして、ページ生成部３３は、アプリケーション処理部３５の処理結果およびタグ処理部３６の処理結果を利用してリプライデータを生成し、応答送信部３８に与える。

ページ記述情報格納部３４は、Ｗｅｂサーバ３０が提供するＷｅｂページを特定するパス名に対応するページ記述情報を格納する。ページ記述情報の形式は、特に限定されるものではない。また、アプリケーション処理部３５は、ページ生成部３３から呼び出され、ページ記述情報に応じた処理を実行してその処理結果をページ生成部３３に返す。

タグ処理部３６は、ページ生成部３３から呼び出され、StrutsのカスタムタグをＨＴＭＬ要素に展開する。ここで、展開により得られたＨＴＭＬ要素がリンク先を表す情報（ここでは、ＵＲＬ）を含むときは、タグ処理部３６は、ＵＲＬエンコード部３７にそのＵＲＬのエンコードを依頼する。また、タグ処理部３６は、ＵＲＬエンコード部３７によりエンコードされたＵＲＬをリンク先としてＨＴＭＬ要素を生成する。そして、タグ処理部３６は、展開結果をページ処理部３３に返す。

ＵＲＬエンコード部３７は、置換情報抽出部３２によってリクエストデータから抽出されたエンコード処理のための情報（置換情報を含む）を保持している。また、ＵＲＬエンコード部３７は、タグ処理部３６からの依頼に応じて、置換情報を利用してＵＲＬをエンコードする。そして、ＵＲＬエンコード部３７は、エンコード結果をタグ処理部３６に返す。なお、ＵＲＬエンコード部３７は、発明に係るＷｅｂサーバ装置が備える書換え部の１つの実施例である。

応答送信部３８は、ページ生成部３３により生成されたページを受け取ると、ＵＲＬエンコード処理を実行したか否かをＵＲＬエンコード部３７に問い合わせる。ＵＲＬエンコード処理が実行されているときは、応答送信部３８は、リプライデータのヘッダ部（すなわち、リプライヘッダ）に、ＵＲＬエンコード処理を実行したことを表す完了報告情報のためのフィールドを追加する。そして、応答送信部３８は、ページ生成部３３により生成されたＷｅｂページを含むリプライデータを中継サーバ１０へ送信する。

次に、実施形態のＷｅｂアプリケーション提供方法の一例を説明する。なお、以下の説明では、図３に示すように、クライアント１とＷｅｂサーバ３０との間に中継サーバ１０が配置されているものとする。Ｗｅｂサーバ３０は、クライアント１のＷｅｂブラウザの目的サーバである。また、中継サーバ１０は図４に示す構成を有し、Ｗｅｂサーバ３０は図５に示す構成を有している。さらに、中継サーバ１０はhttp://proxy.comで識別され、Ｗｅｂサーバ３０はhttp://example.comで識別されるものとする。

＜リクエストの送信＞
クライアント１のユーザは、この実施例では、Ｗｅｂサーバ３０が提供するＷｅｂアプリケーション（app1）のＷｅｂページ（page3）を要求するものとする。この場合、クライアント１のＷｅｂブラウザは、図６に示すＨＴＴＰリクエストを生成して中継サーバ１０へ送信する。この例では、アクセス先として「http-example-com.proxy.com」が設定されている。この記述は、「ＨＴＴＰでproxy.comを経由してexample.comにアクセスする」を意味する。

中継サーバ１０は、クライアント１から図６に示すＨＴＴＰリクエストを受信すると、アクセス先を表すＵＲＬをデコードする。すなわち、中継サーバ１０は、受信したリクエストに設定されているＵＲＬを、目的サーバ（すなわち、Ｗｅｂサーバ３０）を表すＵＲＬに書き換える。この例では、中継サーバ１０は、「http-example-com.proxy.com」を「example.com」に書き換える。なお、ＵＲＬをデコードする手順は、例えば、特開２００９−２７１６７６号公報に記載されている。また、中継サーバ１０は、リクエストヘッダに置換情報を追加する。

図７は、リクエストヘッダに置換情報を追加する処理を示すフローチャートである。このフローチャートの処理は、中継サーバ１０がクライアント１からＨＴＴＰリクエストを受信したときに、置換情報追加部１４により実行される。

ステップＳ１において、置換情報追加部１４は、中継サーバ１０が実行するＵＲＬエンコード方式を表す文字列を生成する。この実施例では、ＵＲＬエンコード方式を表す文字列は、下記の定数文字列である。
hyphen-concatinate-hostname
なお、「文字列を生成」は、中継サーバ１０が備えるメモリ領域に予め格納されている文字列を取得する処理を含むものとする。

ステップＳ２において、置換情報追加部１４は、受信したリクエストのリクエストヘッダに、ステップＳ１で生成した文字列を追加するためのフィールドを追加する。この実施例では、置換情報追加部１４は、リクエストヘッダにX-url-encodetypeフィールドを追加する。そして、置換情報追加部１４は、X-url-encodetypeフィールドに、ステップＳ１で生成した文字列を設定する。

ステップＳ３において、置換情報追加部１４は、中継サーバ１０が実行するＵＲＬエンコードにおいてテンプレートとして使用する文字列を生成する。この実施例では、テンプレートとして使用するＵＲＬエンコードパターンは、下記の定数文字列である。
http://%PROTOCOL%-%HOSTNAME%.proxy.com/%PATHNAME%
「proxy.com」は、中継サーバ１０のホスト名である。なお、「文字列を生成」は、ステップＳ１と同様に、中継サーバ１０が備えるメモリ領域に予め格納されている文字列を取得する処理を含むものとする。

ステップＳ４において、置換情報追加部１４は、受信したリクエストのリクエストヘッダに、ステップＳ３で生成した文字列を追加するためのフィールドを追加する。この実施例では、置換情報追加部１４は、リクエストヘッダにX-url-encodepatternフィールドを追加する。そして、置換情報追加部１４は、X-url-encodepatternフィールドに、ステップＳ３で生成した文字列を設定する。

図８は、置換情報が追加されたＨＴＴＰリクエストの実施例を示す。ここで、図６と図８とを比較すると、アクセス先を表すHOSTが「http-example-com.proxy.com」から「example.com」に書き換えられている。また、図８に示すリクエストには、置換情報として２つのフィールド（X-url-encodetype、X-url-encodepattern）が追加されている。

中継サーバ１０は、上述の置換情報を含むリクエストを目的サーバへ送信する。このリクエストは、「example.com」に従って転送される。よって、Ｗｅｂサーバ３０は、上記リクエストを受信する。

＜Ｗｅｂサーバ３０の動作＞
Ｗｅｂサーバ３０は、中継サーバ１０から図８に示すリクエストを受信すると、ユーザ認証を実行する。そして、ユーザ認証が成功すると、置換情報抽出部３２は、リクエストヘッダから置換情報を抽出する。

図９は、置換情報抽出部３２の処理を示すフローチャートである。このフローチャートの処理は、Ｗｅｂサーバ３０がＨＴＴＰリクエストを受信したときに実行される。
ステップＳ１１において、置換情報抽出部３２は、受信したリクエストが要求するＷｅｂページのプロトコル名、ホスト名、パス名をＵＲＬエンコード部３７に通知する。この実施例では、置換情報抽出部３２は、図８に示すリクエストから、プロトコル名、ホスト名、パス名として、それぞれ「ＨＴＴＰ」「example.com」「app1/page3/html」を抽出する。そして、置換情報抽出部３２は、抽出結果をＵＲＬエンコード部３７に通知する。

ステップＳ１２〜Ｓ１３において、置換情報抽出部３２は、リクエストヘッダに設定されているX-url-encodetypeフィールドの値を取得する。このとき、置換情報抽出部３２は、リクエストヘッダがX-url-encodetypeフィールドを有するか否かをチェックする。また、置換情報抽出部３２は、X-url-encodetypeフィールドの値が、Ｗｅｂサーバ３０が実行可能なエンコード方式を表しているか否かをチェックする。この実施例では、Ｗｅｂサーバ３０は、「hyphen-concatinate-hostname」で識別されるエンコード方式を実行可能であるものとする。

リクエストヘッダがX-url-encodetypeフィールドを有し、且つX-url-encodetypeフィールドの値が、Ｗｅｂサーバ３０が実行可能なエンコード方式を表していれば、処理はステップＳ１４へ移行する。一方、リクエストヘッダがX-url-encodetypeフィールドを有していない場合、或いは、X-url-encodetypeフィールドの値が、Ｗｅｂサーバ３０が実行可能なエンコード方式を表していない場合は、処理はステップＳ１７へ移行する。図８に示す例では、置換情報抽出部３２は、X-url-encodetypeフィールドから下記の値を取得する。
hyphen-concatinate-hostname
この場合、置換情報抽出部３２は、ステップＳ１３で「Ｙｅｓ」と判定する。よって、置換情報抽出部３２は、ステップＳ１４を実行する。

ステップＳ１４〜Ｓ１５において、置換情報抽出部３２は、リクエストヘッダに設定されているX-url-encodepatternフィールドの値を取得する。X-url-encodepatternフィールドに値が設定されていなければ、処理はステップＳ１７へ移行する。図８に示す例では、置換情報抽出部３２は、X-url-encodepatternフィールドから下記の文字列を取得する。
http://%PROTOCOL%-%HOSTNAME%.proxy.com/%PATHNAME%

ステップＳ１６において、置換情報抽出部３２は、ステップＳ１２およびＳ１４で取得して値をＵＲＬエンコード部３７に通知する。ここで、ステップＳ１２で得られた値は、中継サーバ１０およびＷｅｂサーバ３０が実行するＵＲＬエンコード方式を識別する。また、ステップＳ１４で得られた文字列は、Ｗｅｂサーバ３０が実行するＵＲＬエンコードにおいてテンプレートとして使用されるエンコードパターンを有している。

リクエストヘッダがX-url-encodetypeフィールドまたはX-url-encodepatternフィールドを有していないとき、或いは、X-url-encodetypeフィールドまたはX-url-encodepatternフィールドの値が不適切なときは、ステップＳ１７が実行される。ステップＳ１７において、置換情報抽出部３２は、ＵＲＬエンコード処理を実行しないことを表す値をＵＲＬエンコード部３７に通知する。

図１０は、ＵＲＬエンコード部３７が保持するエンコード情報の実施例を示す。ＵＲＬエンコード部３７は、置換情報抽出部３２から通知されるエンコード情報を保持する。このとき、ＵＲＬエンコード部３７は、例えば、Ｗｅｂサーバ３０が受信したＨＴＴＰリクエストのセッションに対応づけて、置換情報抽出部３２から通知されるエンコード情報を保持する。具体的には、ＵＲＬエンコード部３７は、リクエストヘッダから置換情報として抽出される「エンコード方式」および「エンコードパターン文字列」を保持する。さらに、ＵＲＬエンコード部３７は、置換情報と共に「現在のプロトコル名（要求されたプロトコル名）」「現在のホスト名（要求されたホスト名）」「現在のパス名（要求されたパス名）」を保持する。なお、ＵＲＬエンコード部３７は、Ｗｅｂサーバ３０内の所定のメモリ領域にエンコード情報を格納する。

続いて、ページ生成部３３は、ＨＴＴＰリクエストにより要求されたＷｅｂページを生成する。このとき、ページ生成部３３は、まず、ＨＴＴＰリクエストに従って、ページ記述情報格納部３４から対応するページ記述情報を取得する。この例では、ページ生成部３３は、StrutsフレームワークでＷｅｂページを生成するものとする。

図１１は、ページ記述情報の実施例を示す。図１１は、図８に示すＨＴＴＰリクエストに応じてページ記述情報格納部３４から抽出されたページ記述情報を示している。すなわち、このページ記述情報は、Ｗｅｂサーバ３０のパスapp1/page3/htmlで特定されるＷｅｂページの内容を記述している。以下の説明では、app1/page3/htmlで特定されるＷｅｂページのことを「目的Ｗｅｂページ」と呼ぶことがある。なお、ページ記述情報の要素は、この実施例では、ＨＴＭＬタグではなく、taglibによって定義されるカスタムタグで記述されている。

目的Ｗｅｂページは、他のＷｅｂページへのリンクを含んでいる。図１１に示す実施例では、目的Ｗｅｂページには、html:linkタグを利用して「前ページ（page2.html）」および「次ページ（page4.html）」が設定されている。

ページ生成部３３は、ページ記述情報に応じてアプリケーション処理部３５を呼び出して処理を依頼する。そして、ページ生成部３３は、アプリケーション処理部３５の処理結果を受け取る。なお、アプリケーション処理部３５の処理は、公知の技術により実現可能なので、説明は省略する。

さらに、ページ生成部３３は、Strutsのカスタムタグ（即ち、taglibにより定義されるタグ）をＨＴＭＬに展開するために、タグ処理部３６を呼び出す。そして、タグ処理部３６は、StrutsのカスタムタグをＨＴＭＬ要素に展開する。

図１２は、タグ処理部３６の処理を示すフローチャートである。タグ処理部３６は、ページ生成部３３からカスタムタグを受け取ると、このフローチャートの処理を実行する。
ステップＳ２１において、タグ処理部３６は、処理対象のタグ（ページ生成部３３から受け取ったタグ）がhtml:linkタグか否かをチェックする。対象タグがhtml:linkタグであれば、処理はステップＳ２２に移行する。一方、対象タグがhtml:linkタグでなければ、タグ処理部３６はステップＳ２２〜Ｓ２６をスキップする。

ステップＳ２２〜Ｓ２３において、タグ処理部３６は、対象タグのページ属性の値を取得する。そして、タグ処理部３６は、ページ属性の値が完全修飾されたＵＲＬか否かをチェックする。「完全修飾された（Fully Qualified）」とは、ここでは、プロトコル名、ドメイン名、サブドメイン名、ホスト名、パス名等がすべて省略せずに指定されている記述を意味する。

ページ属性の値が完全修飾されたＵＲＬでなければ、タグ処理部３６は、ステップＳ２４において、現在のＷｅｂページのプロトコル名、ホスト名、パス名を用いて、完全修飾されたＵＲＬを作成する。現在のＷｅｂページは、ページ生成部３３が受信したＨＴＴＰリクエストに応じて生成しているページに相当する。したがって、タグ処理部３６は、例えば、受信したＨＴＴＰリクエストのリクエストヘッダから現在のＷｅｂページのプロトコル名、ホスト名、パス名を取得することができる。なお、ページ属性の値が完全修飾されたＵＲＬであれば、タグ処理部３６は、ステップＳ２４をスキップする。

ステップＳ２５において、タグ処理部３６は、ページ属性の値として取得したＵＲＬまたはステップＳ２４で作成したＵＲＬをＵＲＬエンコード部３７へ送信し、エンコード処理を依頼する。また、タグ処理部３６は、ステップＳ２６において、ＵＲＬエンコード部３７によるエンコード結果であるＵＲＬを受け取る。そして、タグ処理部３６は、エンコードされたＵＲＬをページ属性に設定する。なお、ＵＲＬエンコード部３７の処理については、後で詳しく説明する。

ステップＳ２７において、タグ処理部３６は、Strutsフレームワークのタグ置換処理を実行する。ここで、タグ処理部３６は、予め作成されたタグライブラリを備える。そして、タグ処理部３６は、このタグライブラリを利用して、カスタムタグをＨＴＭＬタグに置換する。

図１３は、タグ処理部３６によるＵＲＬの置換処理の実施例を示す。ここでは、ページ生成部３３からタグ処理部３６へ図１１に示す「前ページ」を表すhtml:linkタグが与えられたものとする。この場合、図１２に示すフローチャートでは、タグ処理部３６は、ステップＳ２１において「Ｙｅｓ」と判定する。

ページ記述情報に記述されているＵＲＬ（すなわち、html:linkタグのページ属性の値）は、図１３に示すように「page2.html」である。しかし、このＵＲＬは、プロトコル名、ホスト名、パス名が省略されて記述されている。したがって、図１２に示すフローチャートでは、ステップＳ２４が実行される。

現在のＷｅｂページの「プロトコル名」「ホスト名」「パス名」は、図８に示すＨＴＴＰリクエストによれば、それぞれ「ＨＴＴＰ」「example.com」「app1」である。したがって、タグ処理部３６は、ステップＳ２４において、下記の完全修飾されたＵＲＬを作成する。
http://example.com/app1/page2.html
この後、タグ処理部３６は、ＵＲＬエンコード部３７に対してＵＲＬのエンコード処理を依頼する。ＵＲＬエンコード部３７の処理については、図１４〜図１５を参照しながら説明する。

図１４は、ＵＲＬエンコード部３７の処理を示すフローチャートである。このフローチャートの処理は、ＵＲＬエンコード部３７がタグ処理部３６から呼び出されたときに実行される。なお、タグ処理部３６は、上述したように、html:linkタグを置換する処理の中でＵＲＬエンコード部３７を呼び出す。

ステップＳ３１において、ＵＲＬエンコード部３７は、上述した所定のメモリ領域に保持されているエンコード情報を参照し、「エンコード方式」の値が有効か否か、およびＷｅｂサーバ３０がその値に対応するエンコード方式を実行可能か否か判定する。また、ステップＳ３２において、ＵＲＬエンコード部３７は、上記エンコード情報を参照し、「エンコードパターン文字列」の値が有効か否かを判定する。この実施例では、Ｗｅｂサーバ３０は、「hyphen-concatinate-hostname」で識別されるエンコード方式を実行可能であるものとする。なお、「エンコード方式」または「エンコードパターン文字列」の値が有効でない状態は、例えば、値が設定されていないとき、或いはヌルデータが設定されているときに発生する。

ここで、エンコード情報として保持されている「エンコード方式」は、中継サーバ１０から送信される置換情報の一部であり、中継サーバ１０から要求されたエンコード方式を表す。したがって、ＵＲＬエンコード部３７は、中継サーバ１０から要求されたエンコード方式でＵＲＬをエンコードできるときは、ステップＳ３３〜Ｓ３７の処理を実行する。

ステップＳ３７において、ＵＲＬエンコード部３７は、エンコード前のＵＲＬから、プロトコル名部分、ホスト名部分、パス名部分を抽出する。なお、エンコード前のＵＲＬは完全修飾されたＵＲＬであり、タグ処理部３６から与えられる。

ステップＳ３４において、ＵＲＬエンコード部３７は、ステップＳ３３で抽出したプロトコル名、ホスト名、パス名を、それぞれ指定されたエンコード方式でエンコードする。なお、指定されたエンコード方式は、中継サーバ１０から要求されたエンコード方式である。このエンコード方式の手順は、後で図１５を参照しながら説明する。

ステップＳ３５〜Ｓ３７において、ＵＲＬエンコード部３７は、エンコード情報として保持している「エンコードパターン文字列」を利用して、ＵＲＬエンコード処理を実行する。この実施例では、「エンコードパターン文字列」は以下の文字列である。
http://%PROTOCOL%-%HOSTNAME%.proxy.com/%PATHNAME%
即ち、ステップＳ３５において、ＵＲＬエンコード部３７は、エンコードパターン文字列内の「%PROTOCOL%」を、ステップＳ３４で得られたプロトコル名に置換する。また、ステップＳ３５において、ＵＲＬエンコード部３７は、「%HOSTNAME%」をステップＳ３４で得られたホスト名に置換する。さらに、ステップＳ３５において、ＵＲＬエンコード部３７は、「%PATHNAME%」をステップＳ３４で得られたパス名に置換する。

ステップＳ３８において、ＵＲＬエンコード部３７は、ステップＳ３５〜Ｓ３７で得られた結果文字列をタグ処理部３６に返す。
なお、「エンコード方式」の値が有効でないとき（ステップＳ３１：Ｎｏ）、Ｗｅｂサーバ３０が指定されたエンコード方式を実行できないとき（ステップＳ３１：Ｎｏ）、或いは「エンコードパターン文字列」の値が有効でないときは、ＵＲＬエンコード部３７はステップＳ３９を実行する。この場合、ＵＲＬエンコード部３７は、タグ処理部３６から受け取ったＵＲＬをそのままタグ処理部３６に返す。

図１５は、ＵＲＬエンコード部３７によるエンコード処理の実施例を示す。ここでは、ＵＲＬエンコード部３７は、タグ処理部３６から下記のＵＲＬを受け取るものとする。
http://example.com/app1/page2.html
また、ＵＲＬエンコード部３７は、図１０に示すエンコード情報を保持しているものとする。

ＵＲＬエンコード部３７は、図１０に示すエンコード情報の「エンコード方式」を参照する。この例では、エンコード方式として下記の文字列が記録されている。
hyphen-concatinate-hostname
ここで、Ｗｅｂサーバ３０は、このエンコード方式を実行できる。また、ＵＲＬエンコード部３７は、図１０に示すエンコード情報の「エンコードパターン文字列」を参照する。この例では、エンコードパターン文字列として下記の文字列が記録されている。
http://%PROTOCOL%-%HOSTNAME%.proxy.com/%PATHNAME%
したがって、ＵＲＬエンコード部３７は、ステップＳ３３〜Ｓ３８を実行する。

ＵＲＬエンコード部３７は、ステップＳ３３において、タグ処理部３６から受け取ったＵＲＬからプロトコル名、ホスト名、パス名を抽出する。この例では、ＵＲＬエンコード部３７は、ＵＲＬのプロトコル名、ホスト名、パス名として、図１５に示すように、それぞれ「http」「example.com」「/app1/page2.html」を抽出する。

続いて、ＵＲＬエンコード部３７は、ステップＳ３４において、中継サーバ１０により指定されたエンコード方式（hyphen-concatinate-hostname）で、プロトコル名、ホスト名、パス名をそれぞれエンコードする。このエンコード方式は、以下の規則を含む。
（１）プロトコル名は、変更しない
（２）ホスト名は、ドットをハイフンに置き換える
（３）パス名は、先頭に付されているスラッシュを削除する
したがって、「http」「example.com」「/app1/page2.html」に対して上述のエンコード処理を実行することにより、「http」「example-com」「app1/page2.html」が得られる。

さらに、ＵＲＬエンコード部３７は、ステップＳ３５〜Ｓ３７において、エンコードパターン文字列の「%PROTOCOL%」「%HOSTNAME%」「%PATHNAME%」をそれぞれ「http」「example-com」「app1/page2.html」に置換する。この結果、下記のＵＲＬが生成される。
http://http-example-com.proxy.com/app1/page2/html
そして、ＵＲＬエンコード部３７は、このようにして生成したＵＲＬをタグ処理部３６に返す。

図１６は、ページ生成部３３により生成されるＷｅｂページの実施例を示す。なお、図１６は、ＨＴＭＬ文書内のリンク情報に係わる記述のみを示している。
図１６において、リンク先を表すＵＲＬは、上述したように、ページ記述情報内のＵＲＬを置換情報に従ってエンコード／置換することにより生成される。そして、このＵＲＬの「http-example-com.proxy.com」という記述は、「ＨＴＴＰでproxye.comを経由してexample.comにアクセスする」を意味する。

ページ生成部３３は、上述のようにして生成したＷｅｂページを応答送信部３８に与える。そうすると、応答送信部３８は、このＷｅｂページを含むリプライを中継サーバ１０へ送信する。このとき、応答送信部３８は、ＵＲＬエンコード処理を実行したか否かをＵＲＬエンコード部３７に問い合わせる。そして、ＵＲＬエンコード処理が実行されているときは、応答送信部３８は、リプライヘッダに、ＵＲＬエンコード処理を実行したことを表す完了報告情報のためのフィールドを追加する。

図１７は、Ｗｅｂサーバ３０から送信されるリプライの実施例を示す。ここでは、Ｗｅｂサーバ３０は、中継サーバ１０から置換情報に基づいてＵＲＬエンコード処理を実行したものとする。したがって、この実施例では、Ｗｅｂサーバ３０が実行するＵＲＬエンコード処理はhyphen-concatinate-hostnameである。

この場合、応答送信部３８は、リプライヘッダにX-url-decodetypeフィールドを追加する。図１７では、リプライヘッダの３行目にX-url-decodetypeフィールドが追加されている。さらに、応答送信部３８は、X-url-decodetypeフィールドの値として、Ｗｅｂサーバ３０が実行したＵＲＬエンコード処理を識別する下記の文字列を設定する。hyphen-concatinate-hostname
この結果、図１７に示すリプライが生成される。そして、Ｗｅｂサーバ３０は、図８に示すＨＴＴＰリクエストの送信元である中継サーバ１０へこのリプライを送信する。

なお、Ｗｅｂサーバ３０は、中継サーバ１０から置換情報を受信しなかったときは、上述のＵＲＬエンコード処理を実行しない。また、Ｗｅｂサーバ３０は、置換情報により指定されたエンコード方式をサポートしていないときも、上述のＵＲＬエンコード処理を実行しない。

図１８は、ＵＲＬエンコード処理が実行されなかったときにＷｅｂサーバ３０から送信されるリプライの実施例を示す。この場合、リプライヘッダにX-url-decodetypeフィールドは追加されていない。また、ＨＴＭＬ文書中でリンク先を表すＵＲＬは、中継サーバ１０を経由するための情報を含んでいない。

＜リプライの送信＞
中継サーバ１０は、Ｗｅｂサーバ３０から図１７または図１８に示すリプライを受信する。そうすると、中継サーバ１０は、必要に応じてリプライ中のＷｅｂページを加工した後、そのリプライをクライアント１へ送信する。

図１９は、Ｗｅｂサーバ３０からリプライを受信した中継サーバ１０の処理を示すフローチャートである。中継サーバ１０は、応答受付部１６がＷｅｂサーバ３０からリプライを受信したときに、このフローチャートの処理を実行する。

ステップＳ４１〜Ｓ４２において、応答解釈部１７は、Ｗｅｂサーバ３０から受信したリプライのリプライヘッダからContent-Typeフィールドの値を取得する。そして、応答解釈部１７は、Content-Typeフィールドの値が、ＵＲＬ置換処理を必要とするタイプを表しているか否かをチェックする。Content-Typeフィールドの値がＵＲＬ置換処理を必要とするタイプを表していれば、処理はステップＳ４３へ移行し、そうでない場合は、処理はステップＳ４８へ移行する。

この実施例では、ＷｅｂページがＨＴＭＬ形式であれば、ＵＲＬ置換処理が必要であると判定される。例えば、図１７または図１８に示すリプライにおいては、Content-Typeフィールドに「html」が設定されている。したがって、この場合、応答解釈部１７は、ステップＳ４３〜Ｓ４７を実行する。

ステップＳ４３において、応答解釈部１７は、リプライヘッダからX-url-decodetypeフィールドの値を取得する。また、ステップＳ４４において、応答解釈部１７は、取得したX-url-decodetypeフィールドの値が、中継サーバ１０が実行するＵＲＬエンコード方式を表す文字列と一致するか否かをチェックする。この例では、中継サーバ１０が実行するＵＲＬエンコード方式は、下記の文字列で表わされる。
hyphen-concatinate-hostname
そして、X-url-decodetypeフィールドの値が、中継サーバ１０が実行するＵＲＬエンコード方式を表す文字列と一致するときは、処理はステップＳ４５へ移行する。これに対して、リクエストヘッダがX-url-decodetypeフィールドを有していない場合、X-url-decodetypeフィールドに値が設定されていない場合、X-url-decodetypeフィールドの値が、中継サーバ１０が実行するＵＲＬエンコード方式を表す文字列と一致していない場合は、応答解釈部１７は、リプライをＵＲＬ書換え部１８へ送信する。そして、処理はステップＳ４６へ移行する。

例えば、図１７に示すリプライは、X-url-decodetypeフィールドを有しており、その値はhyphen-concatinate-hostnameである。よって、中継サーバ１０が図１７に示すリプライを受信すると、応答解釈部１７は、Ｗｅｂサーバ３０においてＵＲＬ処理が実行されたと解釈し、ステップＳ４４で「Ｙｅｓ」と判定する。一方、図１８に示すリプライは、X-url-decodetypeフィールドを有していない。したがって、中継サーバ１０が図１８に示すリプライを受信すると、応答解釈部１７は、Ｗｅｂサーバ３０においてＵＲＬ処理が実行されていないと解釈し、ステップＳ４４で「Ｎｏ」と判定する。

ステップＳ４５において、応答解釈部１７は、リプライヘッダからX-url-decodetypeフィールドを削除する。そして、応答解釈部１７は、X-url-decodetypeフィールドが削除されたリプライを応答変換部１９へ送信する。

一方、ステップＳ４６においては、ＵＲＬ書換え部１８は、リプライのＨＴＭＬ文書中のリンク先を表すＵＲＬを書き換える。このとき、ＵＲＬ書換え部１８は、Ｗｅｂサーバ３０のＵＲＬエンコード部３７によるエンコード処理と実質的に同等の書換え処理を実行する。例えば、中継サーバ１０が図１８に示すリプライを受信したときは、ＵＲＬ書換え部１８は、「前ページ」にアクセスするためのＵＲＬを下記のように書き換える。
http://http-example-com.proxy.com/app1/page2/html
また、ＵＲＬ書換え部１８は、「次ページ」を表すＵＲＬについても同様に書き換える。

ステップＳ４７において、応答変換部１９は、リプライを変更する必要があると応答解釈部１７により判定されたときは、セッション管理部１２を参照し、クライアント１のユーザが要求するサービスを識別する。そして、応答変換部１９は、クライアント１のユーザが要求するサービスに応じてリプライを加工する。例えば、ユーザが翻訳サービスを要求しているときは、応答変換部１９は、リプライ中のテキストを翻訳する。あるいは、応答変換部１９は、ユーザが要求する機能を実現するためのスクリプトをリプライに挿入する。

ステップＳ４８において、応答転送部２０は、ステップＳ４１〜Ｓ４７により得られるリプライをクライアント１のＷｅｂブラウザへ送信する。ここで、リプライのＨＴＭＬ文書中にリンク先を表すＵＲＬが記述されているときは、そのＵＲＬは、Ｗｅｂサーバ３０において書き換えられている。また、Ｗｅｂサーバ３０においてＵＲＬエンコード処理が実行されなかったときは、そのＵＲＬは、中継サーバ１０のＵＲＬ書換え部１８により書き換えられる。すなわち、中継サーバ１０からクライアント１へ送信されるリプライのＨＴＭＬ文書中のＵＲＬは、Ｗｅｂサーバ３０または中継サーバ１０により、リンク先へのアクセスが中継サーバ１０を経由して行われるように書き換えられている。中継サーバ１０からクライアント１へ送信されるリプライの実施例を図２０に示す。

クライアント１は、図２０に示すリプライを受信すると、Ｗｅｂブラウザを利用してそのリプライの内容（すなわち、ＨＴＭＬ文書等で記述されるＷｅｂページ）を表示する。このとき、このリプライには、中継サーバ１０が提供するサービスが付加されている。

このような状況において、クライアント１のユーザが、Ｗｅｂブラウザを利用して、例えば、図２０に示す「前ページ」を指定（クリック）するものとする。この場合、Ｗｅｂブラウザは、図２０に示すリプライから得られる下記のＵＲＬへ新たなリクエストを送信する。
http://http-example-com.proxy.com/app1/page2/html
このＵＲＬの「http-example-com.proxy.com」という記述は、少なくともクライアント１のＷｅｂブラウザと中継サーバ１０との間では、「ＨＴＴＰでproxy.comを経由してexample.comにアクセスする」を表す。

したがって、「前ページ」を閲覧するためのリクエストは、クライアント１から中継サーバ１０を経由して目的サーバ（ここでは、Ｗｅｂサーバ３０）へ送信される。Ｗｅｂサーバ３０は、中継サーバ１０から上記リクエストを受信すると、そのリクエストに対応するリプライ（この例では、「前ページ」に相当するＷｅｂページ）を生成して中継サーバ１０へ返送する。そして、中継サーバ１０は、Ｗｅｂサーバ３０から受信したリプライをクライアント１へ転送する。すなわち、「前ページ」に相当するＷｅｂページは、中継サーバ１０を経由してクライアント１に提供される。したがって、クライアント１は、「前ページ」に相当するＷｅｂページについても、中継サーバ１０が提供するサービスを受けることができる。

＜他の実施形態＞
他の実施形態のＷｅｂアプリケーション提供方法において、中継サーバ１０がリクエストに置換情報を追加する手順、およびＷｅｂサーバ３０が置換情報を含むリクエストに基づいてリプライを生成する手順については、図６〜図１８を参照しながら説明した方法と同じである。ただし、他の実施形態の方法は、リプライを受信した中継サーバ１０の処理が図１９に示す手順と異なっている。したがって、以下では、他の実施形態においてリプライを受信した中継サーバ１０の処理を説明する。

図２１は、他の実施形態においてリプライを受信した中継サーバ１０の処理を示すフローチャートである。ここで、図２１に示すステップＳ４１〜Ｓ４４、Ｓ４５、Ｓ４７、Ｓ４８の処理は、図１９を参照しながら説明した通りである。すなわち、他の実施形態においても、リプライヘッダのX-url-decodetypeフィールドの値が、中継サーバ１０のＵＲＬエンコード方式を表す文字列と一致するときは、応答解釈部１７は、リプライヘッダからX-url-decodetypeフィールドを削除する。このとき、中継サーバ１０は、必要応じて、リプライに対してユーザが要求するサービスを付加する。

ところが、他の実施形態においては、リクエストヘッダがX-url-decodetypeフィールドを有していない場合、X-url-decodetypeフィールドに値が設定されていない場合、或いはX-url-decodetypeフィールドの値が中継サーバ１０のＵＲＬエンコード方式を表す文字列と一致していない場合は、応答解釈部１７は、リプライを応答転送部２０へ送信する。すなわち、Ｗｅｂサーバ３０においてＵＲＬエンコード処理が実行されなかったときは、中継サーバ１０は、ＵＲＬ書換え部１８によるＵＲＬ書換え処理、および応答変換部１９によるＷｅｂページの変更を行うことなく、Ｗｅｂサーバ３０により生成されたリプライをクライアント１へ送信する。

この場合、クライアント１が受信するＷｅｂページには、中継サーバ１０が提供するサービスは付加されていない。また、クライアント１がＷｅｂブラウザを利用してＷｅｂページ内のＵＲＬにアクセスすると、リクエストは、中継サーバ１０を経由せずにアクセス先へ転送される。したがって、そのアクセス先から送信されるＷｅｂページにも、中継サーバ１０が提供するサービスは付加されない。

このように、Ｗｅｂサーバ３０においてＷｅｂページ中のＵＲＬが書き換えられているときは、中継サーバ１０は、リプライの内容の変更を許可する。一方、Ｗｅｂサーバ３０においてＷｅｂページ中のＵＲＬが書き換えられてないときは、中継サーバ１０は、リプライの内容の変更を禁止する。

この構成により、Ｗｅｂサーバ３０は、あるリンク先へのアクセスが中継サーバ１０を経由しないように制限することができる。すなわち、Ｗｅｂサーバ３０がＷｅｂページ内のＵＲＬを書き換えなければ、クライアント１が受信するＷｅｂページ内のＵＲＬは、目的サーバを指し示す状態を維持している。この場合、クライアント１のＷｅｂブラウザがそのＵＲＬを指定すると、リクエストは、中継サーバ１０を経由することなく目的サーバへ転送される。そして、目的サーバからクライアント１へ提供されるリプライも、中継サーバ１０を経由しない。したがって、目的サーバからクライアント１へ提供されるリプライは、中継サーバ１０によって加工または変更されることはない。すなわち、Ｗｅｂサーバ３０は、中継サーバ１０により加工または変更されたくないコンテンツを保護できる。

一方、中継サーバ１０は、リプライデータに完了報告情報（X-url-decodetypeフィールド）が付与されていないときは、ＵＲＬ書換え部１８によるＵＲＬ書換え処理、および応答変換部１９によるＷｅｂページの変更を行わない。よって、Ｗｅｂサーバ３０は、完了報告情報を、中継サーバ１０におけるＵＲＬの書換えの可否およびＷｅｂページの加工の可否を表す情報として使用することもできる。

＜中継サーバ１０およびＷｅｂサーバ３０のハードウェア構成＞
図２２は、中継サーバ１０およびＷｅｂサーバ３０を実現するためのコンピュータシステム１００のハードウェア構成を示す図である。コンピュータシステム１００は、図２２に示すように、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、読み取り装置１０４、通信インタフェース１０６、入出力装置１０７を備える。ＣＰＵ１０１、メモリ１０２、記憶装置１０３、読み取り装置１０４、通信インタフェース１０６、入出力装置１０７は、例えば、バス１０８を介して互いに接続されている。

ＣＰＵ１０１は、メモリ１０２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、実施形態の中継サーバ１０またはＷｅｂサーバ３０の機能を提供する。コンピュータシステム１００が中継サーバ１０として動作するときは、ＣＰＵ１０１は、図７および図１９（他の実施形態においては、図１９に代わりに図２１）に示すフローチャートの手順を記述したプログラムを実行し、図４に示す要素１１〜２０の機能の一部または全部を提供する。また、コンピュータシステム１００がＷｅｂサーバ３０として動作するときは、ＣＰＵ１０１は、図９、図１２、図１４に示すフローチャートの手順を記述したプログラムを実行し、図５に示す要素３１〜３３、３５〜３８の機能の一部または全部を提供する。

メモリ１０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んで構成される。記憶装置１０３は、例えばハードディスクであり、実施形態の手順を記述したプログラムを格納する。記憶装置１０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置１０３は、外部記録装置であってもよい。なお、コンピュータシステム１００が中継サーバ１０として動作するときは、ユーザ情報ＤＢ２１は、例えば、記憶装置１０３に設けられる。また、コンピュータシステム１００がＷｅｂサーバ３０として動作するときは、ページ記述情報格納部３４は、例えば、記憶装置１０３に設けられる。

読み取り装置１０４は、ＣＰＵ１０１の指示に従って可搬型記録媒体１０５にアクセスする。可搬型記録媒体１０５は、例えば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。通信インタフェース１０６は、ＣＰＵ１０１の指示に従ってネットワークを介してデータを送受信する。入出力装置１０７は、例えば、ユーザからの指示を受け付けるデバイス、ＣＰＵ１０１の処理結果を表示するデバイス等に相当する。

中継サーバ１０またはＷｅｂサーバ３０の処理に係わるプログラムは、例えば、下記の形態でコンピュータシステム１００に提供される。
（１）記憶装置１０３に予めインストールされている。
（２）可搬型記録媒体１０５により提供される。
（３）プログラムサーバ１１０からダウンロードする。

１ クライアント
１０ 中継サーバ
１１ 要求受付部
１２ セッション管理部
１３ サブドメイン解釈部
１４ 置換情報追加部
１５ 要求転送部
１６ 応答受付部
１７ 応答解釈部
１８ ＵＲＬ書換え部
１９ 応答変換部
２０ 応答転送部
２１ ユーザ情報データベース
３０ Ｗｅｂサーバ（目的サーバ）
３１ 要求受付部
３２ 置換情報抽出部
３３ ページ生成部
３４ ページ記述情報格納部
３５ アプリケーション処理部
３６ タグ処理部
３７ ＵＲＬエンコード部
３８ 応答送信部

Claims (10)

1. Ｗｅｂサーバから中継サーバを介してクライアントへＷｅｂアプリケーションを提供する方法であって、
   前記中継サーバは、前記クライアントから受信するリクエストに、前記Ｗｅｂサーバが提供するＷｅｂページ中に設定されているＵＲＬへのアクセスが前記中継サーバを経由するように、前記ＵＲＬを書き換えるための置換情報を追加し、
   前記中継サーバは、前記置換情報を含むリクエストを前記Ｗｅｂサーバへ送信し、
   前記Ｗｅｂサーバは、前記リクエストに従って応答Ｗｅｂページを生成し、
   前記Ｗｅｂサーバは、前記応答Ｗｅｂページ中に設定されるＵＲＬを前記置換情報に基づいて書き換え、
   前記Ｗｅｂサーバは、前記置換情報に基づいて書き換えられたＵＲＬを含む前記応答Ｗｅｂページを前記中継サーバへ送信し、
   前記中継サーバは、前記応答Ｗｅｂページを前記クライアントへ送信する
   ことを特徴とするＷｅｂアプリケーション提供方法。
2. 請求項１に記載のＷｅｂアプリケーション提供方法であって、
   前記置換情報は、予め決められたパターンの文字列を含み、
   前記Ｗｅｂサーバは、前記文字列の一部を前記応答Ｗｅｂページのプロトコル名、ホスト名、パス名の中の少なくとも１つを表す文字列に置換することにより、前記ＵＲＬを書き換える
   ことを特徴とするＷｅｂアプリケーション提供方法。
3. クライアントとＷｅｂサーバとの間に配置される中継サーバに、
   前記クライアントから受信するリクエストに、前記Ｗｅｂサーバが提供するＷｅｂページ中に設定されるＵＲＬへのアクセスが前記中継サーバを経由するように、前記ＵＲＬを書き換えるための置換情報を追加し、
   前記置換情報を含むリクエストを前記Ｗｅｂサーバへ送信し、
   前記Ｗｅｂサーバにおいて前記リクエストに応じて生成されたＷｅｂページを含むリプライを前記Ｗｅｂサーバから受信し、
   前記リプライを前記クライアントへ送信する
   処理を実行させるプログラム。
4. 前記中継サーバに、
   前記Ｗｅｂサーバにおいて前記置換情報に基づいて前記Ｗｅｂページ中のＵＲＬが書き換えられたか否かを判定し、
   前記Ｗｅｂサーバにおいて前記Ｗｅｂページ中のＵＲＬが書き換えられてないときは、前記Ｗｅｂページ中のＵＲＬへのアクセスが前記中継サーバを経由するように、前記Ｗｅｂページ中のＵＲＬを書き換える、
   処理をさらに実行させる請求項３に記載のプログラム。
5. 前記中継サーバに、
   前記Ｗｅｂサーバにおいて前記置換情報に基づいて前記Ｗｅｂページ中のＵＲＬが書き換えられたか否かを判定し、
   前記Ｗｅｂサーバにおいて前記Ｗｅｂページ中のＵＲＬが書き換えられているときは、前記リプライの内容の変更を許可し、前記Ｗｅｂサーバにおいて前記Ｗｅｂページ中のＵＲＬが書き換えられてないときは、前記リプライの内容の変更を禁止する
   処理をさらに実行させる請求項３に記載のプログラム。
6. 前記中継サーバに、
   前記リプライの内容を変更する処理をさらに実行させる請求項３に記載のプログラム。
7. Ｗｅｂサーバに、
   クライアントから送信され、中継サーバにおいて置換情報が追加されたリクエストを受信し、
   前記リクエストに従ってＷｅｂページを生成し、
   前記Ｗｅｂページ中に設定されるＵＲＬを、前記置換情報に基づいて、前記ＵＲＬへのアクセスが前記中継サーバを経由するように書き換え、
   前記置換情報に基づいて書き換えられたＵＲＬを含む前記Ｗｅｂページを前記中継サーバへ送信する
   処理を実行させるプログラム。
8. 前記Ｗｅｂサーバに、
   前記ＵＲＬが前記置換情報に基づいて書き換えられたときは、前記ＵＲＬが書き換えられたことを表す完了報告情報を前記リプライに追加する処理をさらに実行させる
   ことを特徴とする請求項７に記載のプログラム。
9. クライアントとＷｅｂサーバとの間に配置される中継サーバ装置であって、
   前記クライアントから受信するリクエストに、前記Ｗｅｂサーバが提供するＷｅｂページ中に設定されるＵＲＬへのアクセスが前記中継サーバを経由するように、前記ＵＲＬを書き換えるための置換情報を追加する追加部と、
   前記置換情報を含むリクエストを前記Ｗｅｂサーバへ送信する要求転送部と、
   前記Ｗｅｂサーバにおいて前記リクエストに応じて生成されたＷｅｂページを含むリプライを前記Ｗｅｂサーバから受信する応答受付部と、
   前記リプライを前記クライアントへ送信する応答転送部、
   を有する中継サーバ装置。
10. クライアントから送信され、中継サーバにおいて置換情報が追加されたリクエストを受信する要求受付部と、
    前記リクエストに従ってＷｅｂページを生成するページ生成部と、
    前記Ｗｅｂページ中に設定されるＵＲＬを、前記置換情報に基づいて、前記ＵＲＬへのアクセスが前記中継サーバを経由するように書き換える書換え部と、
    前記書換え部により書き換えられたＵＲＬを含む前記Ｗｅｂページを前記中継サーバへ送信する応答送信部、
    を有するＷｅｂサーバ装置。