JP5151696B2 - ユニフォームリソースロケータ情報を書き換えるプログラム - Google Patents

Description

本発明は、Ｗｅｂページに含まれるユニフォームリソースロケータ（ＵＲＬ）情報を書き換えるプログラムに関する。

クライアント端末からＷｅｂサーバ上のＷｅｂページにアクセスする際、クライアント端末とＷｅｂサーバの通信を中継するサーバとして、翻訳サーバやポータルサーバ等がある。翻訳サーバは、例えば、英語のＷｅｂページを配信するＷｅｂサーバにアクセスし、受け取ったＷｅｂページの英文を日本語に翻訳してクライアント端末に送る。また、ポータルサーバは、例えば、Ｗｅｂサーバが配信する地図等のＷｅｂページを自身のＷｅｂページに貼り付けてクライアント端末に送る。

このような中継システムでは、ユーザがクライアント端末の画面に表示されたＷｅｂページ内のリンク等をクリックしたとき、再び中継サーバを経由してＷｅｂサーバにアクセスできる必要がある。例えば、翻訳サーバで翻訳済みのページ内にあるリンク等がクリックされたとき、そのリンク先のページも翻訳済みで表示するためには、中継サーバを介してＷｅｂサーバにアクセスする必要がある。

そこで、中継サーバは、元のＷｅｂサーバから受け取ったHyperText Markup Language （ＨＴＭＬ）文書をクライアント端末に送る際に、ＨＴＭＬ文書内のＵＲＬを書き換える。

図２６は、このような従来のＵＲＬ書換方法を示している。中継サーバ１２の読込部３２は、元サーバ１３からＷｅｂページ２２を読み込み、解析部３４は、そのＷｅｂページ２２を解析し、書換部３３は、Ｗｅｂページ２２内のＵＲＬを書き換える。ここでは、ＨＴＭＬ文書内のａタグやｆｏｒｍタグ等、サーバへの送信動作が記述された箇所が書き換えられる。送信部３１は、書換済みＷｅｂページ２１をクライアント端末１１に送信する。

クライアント端末がアクセス先のＵＲＬを変更するシステムも知られており（例えば、特許文献１を参照）、中継サーバがリクエスト履歴内のリクエストを選択してパスを再生するシステムも知られている（例えば、特許文献２を参照）。
特開２００２−０３２２７３号公報 特表２００３−５３０６２５号公報

しかしながら、上述した従来の中継システムには、次のような問題がある。
（１）中継サーバでＵＲＬを書き換えなければいけないので、中継サーバのリソースを消費する。
（２）クライアント端末がＪａｖａＳｃｒｉｐｔ等により動的にＵＲＬを生成している場合には、ＵＲＬを書き換えることができない。
（３）非同期通信の場合には、JavaScriptのプログラム等により動的にURLを生成するため、ＵＲＬを書き換えることができない。

本発明の課題は、クライアント端末が動的にＵＲＬを生成する場合や非同期通信を行う場合でも、元サーバのＵＲＬを中継サーバ経由のＵＲＬに書き換えられるようにすること
である。

開示のシステムにおいて、クライアント端末は、元サーバのページ情報と書換プログラムを中継サーバから受信する。そして、受信した書換プログラムを実行することで、ユニフォームリソースロケータ情報中の元サーバのサーバ名が中継サーバのサーバ名に変更されるように、そのページ情報を書き換える。

次に、受信したページ情報の記述に基づき元サーバへのリクエストを生成し、そのリクエストに含まれるユニフォームリソースロケータ情報中の元サーバのサーバ名を中継サーバのサーバ名に変更する。そして、変更後のユニフォームリソースロケータ情報に基づいてリクエストを中継サーバに送信する。

このようなシステムによれば、中継サーバがＵＲＬを書き換えるのではなく、クライアント端末が元サーバへのリクエストを送信するときにＵＲＬが書き換えられる。したがって、リクエストが動的に生成された場合や非同期通信が行われる場合でも、元サーバのＵＲＬを中継サーバ経由のＵＲＬに書き換えることができる。

開示のシステムによれば、クライアント端末が動的にＵＲＬを生成する場合や非同期通信を行う場合でも、元サーバのＵＲＬを中継サーバ経由のＵＲＬに書き換えることができる。

以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
実施形態のＵＲＬ書換システムでは、中継サーバではなくクライアント端末で、Ｗｅｂサーバへのリクエストに含まれるＵＲＬのサーバ名を、中継サーバのサーバ名に書き換える。そのために、中継サーバは、Ｗｅｂサーバから送信されるＷｅｂページのＨＴＭＬ文書に、ＵＲＬを書き換える機能を備える書換プログラム（書換スクリプト）を付加して、クライアント端末に送信する。

図１は、このようなＵＲＬ書換システムの構成例を示している。中継サーバ１０２の読込部１２２は、元サーバ１０３からＷｅｂページ１１１を読み込む。Ｗｅｂページ１１１には、ＪａｖａＳｃｒｉｐｔが含まれる場合がある。送信部１２１は、書換スクリプト１１２の読み込みを指示するタグをＷｅｂページ１１１に埋め込んで、書換スクリプト１１２とともにＷｅｂページ１１１をクライアント端末１０１に送信する。

クライアント端末１０１のブラウザは、Ｗｅｂページ１１１を画面に表示する。このとき、ブラウザは、書換スクリプト１１２を読み込む。書換スクリプト１１２は、ブラウザ上で動作し、Ｗｅｂページ１１１のＨＴＭＬ文書内で、ブラウザからサーバにリクエストを送信する処理が記述された箇所を書き換える。これにより、次のリクエストの送信先ＵＲＬのサーバ名が中継サーバ１０２のサーバ名に変更される。

中継サーバ１０２は、Ｗｅｂページ１１１に書換スクリプト１１２の読みこみ指示を付加して送信するだけでよいので、Ｗｅｂページ１１１全体を書き換える場合に比べて、極めて短時間で処理が完了する。

基本的には、ＨＴＭＬ文書のロード時にその書換が行われるため、書換用ＪａｖａＳｃｒｉｐｔが以下のような関数内に実装される。

window.onload = function(){...}

図２は、書き換えられたＷｅｂページ１１１における、ブラウザの基本動作を示している。ユーザ操作やＷｅｂページ１１１の動作によりボタンやリンクがクリックされると（手順２０１）、ブラウザは、発生イベントに応じた送信動作を行う（手順２０２）。このとき、ブラウザは、ＨＴＭＬ文書の記述に従ってＵＲＬ書換処理を行ってから（手順２０３）、本来の送信処理を行う（手順２０４）。その後、ブラウザは、中継サーバ１０２にリクエストを送信する（手順２０５）。

例えば、中継サーバ１０２のＵＲＬと、リクエスト先である元サーバ１０３のＷｅｂページのＵＲＬが、以下のようなものであったとする。

中継サーバ http://www.mycompany.com/
Ｗｅｂページ http://www.othercompany.com/ap/page.html

この場合、ＷｅｂページのＵＲＬは、例えば、次のように書き換えられる。

（例１） http://www.mycompany.com/?http://www.othercompany.com/ap/page.html
（例２） http://www.othercompnay.com.www.mycompany.com/ap/page.html

例１では、中継サーバ１０２のＵＲＬに続いて“？”が挿入され、ＷｅｂページのＵＲＬが接続されている。また、例２では、中継サーバ１０２のサーバ名“www.mycompany.com”の手前に元サーバ１０３のサーバ名“www.othercompnay.com”が挿入され、“www.mycompany.com/”の後ろにＷｅｂページのパス名が接続されている。

ＨＴＭＬ文書の書換パターンは、書換対象に応じて以下のように分類される。
（１）フォーム
ｆｏｒｍの場合、リクエスト送信のタイミングは、以下の２種類に分類される。

（ａ）ｆｏｒｍ内のＪａｖａＳｃｒｉｐｔ Application Program Interface （ＡＰＩ）であるｆｏｒｍ．ｓｕｂｍｉｔ（）関数によるリクエストの場合は、ｆｏｒｍのｓｕｂｍｉｔ関数が呼び出される。そこで、ｓｕｂｍｉｔ関数の中でリクエスト先ＵＲＬが変更されるように、ｓｕｂｍｉｔ関数を書き換える。

（ｂ）ｆｏｒｍ内の<input type=“submit”>で指定されるボタンによるリクエストの場合は、ｆｏｒｍのｓｕｂｍｉｔ関数は呼び出されない。そこで、このボタンにクリックリスナ（クリックイベントハンドラ）を追加し、その中でｆｏｒｍのｓｕｂｍｉｔ関数を呼び出すように、ボタンのｓｕｂｍｉｔ時の動作を書き換える。そして、上記（ａ）と同様に、ｓｕｂｍｉｔ関数を書き換える。

（２）アンカー（ａタグ）
<a href=“...”>で記述されるａタグによるｓｕｂｍｉｔ動作については、そのｈｒｅｆ要素を書き換えてリクエスト先ＵＲＬが変更されるように、ａタグのクリック時の動作を書き換える。

（３）イメージ、スタイルシート、及びスクリプト
イメージ、スタイルシート、又はスクリプトの場合、対応するｉｍｇタグのｓｒｃ属性、ｌｉｎｋタグのｈｒｅｆ属性、又はｓｃｒｉｐｔタグのｓｒｃ属性を直接書き換えることで、リクエスト先ＵＲＬを変更する。例えば、以下のようなタグが記述されている場合を考える。

<img src=“images/myimg.jpg”>
<link type=“stylesheet” href=“css/mypage.css”>
<script src=“scripts/mylib.js”>

これらのタグは、次のように書き換えられる。

<img src=“http://www.mycompany.com/?images/myimg.jpg”>
<link type=“stylesheet” href=“http://www.mycompany.com/?css/mypage.css”>
<script src=“http://www.mycompany.com/?scripts/mylib.js”>

（４）非同期通信
非同期通信でＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトを利用する場合、送信時にリクエスト先ＵＲＬが変更されるように、オブジェクト自身の定義を書き換える。ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトのＵＲＬは、以下のようにｏｐｅｎ関数により指定される。

var con = new XMLHttpRequest();
con.open(“GET”, “search”, true);

そこで、ｏｐｅｎ関数の呼び出し時にリクエスト先ＵＲＬが変更されるように、ｏｐｅｎ関数の第２引数を、中継サーバ１０２を経由するＵＲＬに書き換える。

図３は、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトによるリクエスト送信動作を示している。ユーザ操作やＷｅｂページ１１１の動作によりＸＭＬＨｔｔｐＲｅｑｕｅｓｔが生成されると（手順３０１）、ブラウザは、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトを生成する（手順３０２）。このとき、ブラウザは、書換後のｏｐｅｎ関数に従ってＵＲＬ書換処理を行ってから（手順３０３）、送信処理を行う（手順３０４）。その後、ブラウザは、中継サーバ１０２にリクエストを送信する（手順３０５）。

（５）Document Object Model （ＤＯＭ） ＡＰＩによる書換
Ｗｅｂページ１１１内にＪａｖａＳｃｒｉｐｔが含まれており、Ｗｅｂページ１１１内で要素が動的に生成される場合、生成関数を書き換える。これにより、生成された要素によるリクエスト送信時に、リクエスト先ＵＲＬが変更されるようにする。ＤＯＭ ＡＰＩは、次のようにして要素を生成する。

var anchor = document.createElement(“a”);
anchor.href = “mypage.html”;

このｃｒｅａｔｅＥｌｅｍｅｎｔ関数を書き換えることで、ｆｏｒｍ、アンカー、イメージ、スタイルシート、又はスクリプトが生成されたとき、その要素によりリクエストが送信されるときの動作を変更することができる。

図４は、ＤＯＭ ＡＰＩ動作に基づくリクエスト送信動作を示している。ユーザ操作やＷｅｂページ１１１の動作によりＤＯＭ ＡＰＩが動作すると（手順４０１）、ブラウザは、ｃｒｅａｔｅＥｌｅｍｅｎｔ関数によりオブジェクト（要素）を生成する（手順４０２）。このとき、ブラウザは、書換後のｃｒｅａｔｅＥｌｅｍｅｎｔ関数に従ってオブジェクト書換処理を行う（手順４０３）。

その後、ユーザ操作やＷｅｂページ１１１の動作によりリクエストが発行されると（手順４０４）、ブラウザは、書換後のオブジェクトに従ってＵＲＬを書き換え、送信処理を行う（手順４０５）。その後、ブラウザは、中継サーバ１０２にリクエストを送信する（手順４０６）。

（６）ｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ構文又はｉｎｎｅｒＨＴＭＬ構文
Ｗｅｂページ１１１内にＪａｖａＳｃｒｉｐｔが含まれており、ｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ又はｉｎｎｅｒＨＴＭＬによりＷｅｂページ１１１が変更される場合、指定される文字列に何が含まれるか分からない。このため、ｃｒｅａｔｅＥｌｅｍｅｎｔ関数のように、生成される要素を想定した処理を行うことができない。この場合の対処方法としては、次の２種類がある。

（ａ）ｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ又はｉｎｎｅｒＨＴＭＬによりＷｅｂページ１１１が変更される場合、ＤＯＭ変更イベントが発生する。そこで、この変更イベントを捉えることにより、変更部分を取得してＵＲＬを書き換えることができる。例えば、初期化時に、以下のようなＤＯＭイベントリスナを追加しておく。

document.addEventListener(“MutationEvent”, rewrite, true);

これにより、Ｗｅｂページ１１１の変更時にｒｅｗｒｉｔｅ関数が呼び出され、ｒｅｗｒｉｔｅ関数によりオブジェクト書換処理を行うことができる。

図５は、ＤＯＭ変更イベント受信に基づくリクエスト送信動作を示している。ユーザ操作やＷｅｂページ１１１の動作によりｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ又はｉｎｎｅｒＨＴＭＬが動作すると（手順５０１）、ブラウザは、ＤＯＭイベントリスナによりＤＯＭ変更イベントを受信する（手順５０２）。このとき、ブラウザは、ｒｅｗｒｉｔｅ関数等に従ってオブジェクト書換処理を行う（手順５０３）。

その後、ユーザ操作やＷｅｂページ１１１の動作によりリクエストが発行されると（手順５０４）、ブラウザは、書換後のオブジェクトに従ってＵＲＬを書き換え、送信処理を行う（手順５０５）。その後、ブラウザは、中継サーバ１０２にリクエストを送信する（手順５０６）。

（ｂ）一部のブラウザに見られるように、ＤＯＭイベントがサポートされていない場合は、ｓｅｔＩｎｔｅｒｖａｌのような定時監視関数を用いて変更イベントを監視する。例えば、初期化時に、以下のようなｓｅｔＩｎｔｅｒｖａｌ関数を追加しておく。

setInterval(check, 100);

これにより、１００ミリ秒毎にｃｈｅｃｋ関数が呼び出され、Ｗｅｂページ１１１が変更されたか否かをチェックする。Ｗｅｂページ１１１が変更されていれば、変更部分が解析され、必要であればオブジェクト書換処理が行われる。

図６は、監視動作に基づくリクエスト送信動作を示している。ユーザ操作やＷｅｂページ１１１の動作によりｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ又はｉｎｎｅｒＨＴＭＬが動作すると（手順６０１）、ブラウザは、ｃｈｅｃｋ関数により変更イベントを検知する（手順６０２）。このとき、ブラウザは、必要であればオブジェクト書換処理を行う（手順６０３）。

その後、ユーザ操作やＷｅｂページ１１１の動作によりリクエストが発行されると（手順６０４）、ブラウザは、書換後のオブジェクトに従ってＵＲＬを書き換え、送信処理を行う（手順６０５）。その後、ブラウザは、中継サーバ１０２にリクエストを送信する（手順６０６）。

以上説明した（１）〜（６）の書換パターンを書換スクリプト１１２に記述することで、どのような状況においても、クライアント端末１０１からのリクエストが中継サーバ１０２を経由するように、ＵＲＬを変更することが可能になる。なお、（１）〜（６）の書換パターンの一部のみを含む書換スクリプト１１２を用いることも可能である。

図７は、Ｗｅｂページ１１１の例を示しており、図８は、書換スクリプト１１２の例を示している。図８の書換スクリプトでは、中継サーバ１０２のＵＲＬとして“http://localhost:8080/”が用いられている。この書換スクリプトのスクリプト部分８０１は、非同期通信リクエスト７０１を書き換える。また、スクリプト部分８０２は、ｆｏｒｍ内のｓｕｂｍｉｔ関数のリクエスト７０３を書き換え、スクリプト部分８０３は、ｆｏｒｍ内のボタンによるリクエスト７０２を書き換える。

図１のようなＵＲＬ書換システムによれば、次のような効果が得られる。
（１）中継サーバでのＵＲＬ書換処理が不要なため、中継サーバの負荷が劇的に低減される。
（２）クライアント端末が動的にＵＲＬを生成している場合でも、ＵＲＬを書き換えることができる。
（３）非同期通信の場合でも、ＵＲＬを書き換えることができる。

次に、図９から図２３までを参照しながら、複数の書換パターンを含む書換スクリプト１１２を用いた場合のブラウザの処理について説明する。
図９は、ブラウザによる初期化処理のフローチャートである。ブラウザは、まず、中継サーバ１０２から受信したＷｅｂページ１１１のＨＴＭＬ文書と書換スクリプト１１２を読み込む（ステップ９０１）。

次に、書換スクリプト１１２に従って、フォーム書換処理（ステップ９０２）、ｓｕｂｍｉｔボタン書換処理（ステップ９０３）、ａタグ書換処理（ステップ９０４）、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ書換処理（ステップ９０５）、及びＤＯＭ ＡＰＩ書換処理（ステップ９０６）を行う。

次に、ＤＯＭイベントがサポートされているか否かをチェックし（ステップ９０７）、ＤＯＭイベントがサポートされていれば、ＤＯＭイベント登録処理を行う（ステップ９０８）。一方、ＤＯＭイベントがサポートされていなければ、ｓｅｔＩｎｔｅｒｖａｌ登録処理を行う（ステップ９０９）。

図１０は、図９のステップ９０２におけるフォーム書換処理のフローチャートである。ブラウザは、ＨＴＭＬ文書内のフォームをすべて取得する（ステップ１００１）。そして、各フォームのｓｕｂｍｉｔ関数をｓｕｂｍｉｔ０として保存し（ステップ１００２）、各フォームのｓｕｂｍｉｔ関数を書換後ｓｕｂｍｉｔ関数に置き換える（ステップ１００３）。書換後ｓｕｂｍｉｔ関数は、リクエスト先のＵＲＬを中継サーバ１０２を経由するＵＲＬに変更する機能を持つ。

図１１は、図９のステップ９０３におけるｓｕｂｍｉｔボタン書換処理のフローチャートである。ブラウザは、ＨＴＭＬ文書内のボタンをすべて取得し（ステップ１１０１）、
各ボタンのｔｙｐｅが“ｓｕｂｍｉｔ”か否かをチェックする（ステップ１１０２）。そして、ボタンのｔｙｐｅが“ｓｕｂｍｉｔ”であれば、そのボタンのクリックリスナとして書換後ｓｕｂｍｉｔ関数を登録する（ステップ１１０３）。

図１２は、図９のステップ９０４におけるａタグ書換処理のフローチャートである。ブラウザは、ＨＴＭＬ文書内のａタグをすべて取得し（ステップ１２０１）、各ａタグのクリックリスナを登録する（ステップ１２０２）。ａタグのクリックリスナは、リクエスト先のＵＲＬを中継サーバ１０２を経由するＵＲＬに変更する機能を持つ。

図１３は、図９のステップ９０５におけるＸＭＬＨｔｔｐＲｅｑｕｅｓｔ書換処理のフローチャートである。ブラウザは、ＨＴＭＬ文書内のＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｐｒｏｔｏｔｙｐｅ．ｏｐｅｎ関数をＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｐｒｏｔｏｔｙｐｅ．ｏｐｅｎ０として保存する（ステップ１３０１）。そして、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｐｒｏｔｏｔｙｐｅ．ｏｐｅｎ関数を書換後ｏｐｅｎ関数に置き換える（ステップ１３０２）。書換後ｏｐｅｎ関数は、リクエスト先のＵＲＬを中継サーバ１０２を経由するＵＲＬに変更する機能を持つ。

図１４は、図９のステップ９０６におけるＤＯＭ ＡＰＩ書換処理のフローチャートである。ブラウザは、ＨＴＭＬ文書内のｄｏｃｕｍｅｎｔ．ｃｒｅａｔｅＥｌｅｍｅｎｔ関数をｄｏｃｕｍｅｎｔ．ｃｒｅａｔｅＥｌｅｍｅｎｔ０として保存する（ステップ１４０１）。そして、ｄｏｃｕｍｅｎｔ．ｃｒｅａｔｅＥｌｅｍｅｎｔ関数を書換後ｃｒｅａｔｅＥｌｅｍｅｎｔ関数に置き換える（ステップ１４０２）。書換後ｃｒｅａｔｅＥｌｅｍｅｎｔ関数は、リクエスト先のＵＲＬを変更するために、生成された要素を書き換える機能を持つ。

図１５は、図９のステップ９０８におけるＤＯＭイベント登録処理のフローチャートである。ブラウザは、ＨＴＭＬ文書内のＤＯＭオブジェクトをすべて取得し（ステップ１５０１）、各ＤＯＭオブジェクトのＤＯＭイベントリスナとしてＤＯＭ書換処理を登録する（ステップ１５０２）。ＤＯＭイベントリスナは、リクエスト先のＵＲＬを変更するために、生成された要素を書き換える機能を持つ。

図１６は、図９のステップ９０９におけるｓｅｔＩｎｔｅｒｖａｌ登録処理のフローチャートである。ブラウザは、ｓｅｔＩｎｔｅｒｖａｌを監視処理として登録する（ステップ１６０１）。登録されたｓｅｔＩｎｔｅｒｖａｌは、変更イベントを監視する。

図１７〜図２３は、初期化処理の終了後にユーザ操作やＷｅｂページ１１１の動作によりイベントが発生した場合の、リクエスト送信処理及びオブジェクト書換処理を示している。

図１７は、フォームのｓｕｂｍｉｔが実行されたとき、又はｓｕｂｍｉｔボタンがクリックされたときに行われる送信処理のフローチャートである。ブラウザは、まず、ｓｕｂｍｉｔ関数として登録されている書換後ｓｕｂｍｉｔ関数を呼び出し、リクエスト先のＵＲＬを中継サーバ１０２を経由するＵＲＬに変更する（ステップ１７０１）。そして、保存されているｓｕｂｍｉｔ０（本来のｓｕｂｍｉｔ関数）を実行する（ステップ１７０２）。これにより、中継サーバ１０２に対してリクエストが送信される。

図１８は、ａタグがクリックされたときに行われる送信処理のフローチャートである。ブラウザは、まず、ａタグのクリックリスナを用いてリクエスト先のＵＲＬを中継サーバ１０２を経由するＵＲＬに変更する（ステップ１８０１）。そして、ａタグのリクエストを実行する（ステップ１８０２）。これにより、中継サーバ１０２に対してリクエストが
送信される。

図１９は、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトのｏｐｅｎが実行されたときに行われる送信処理のフローチャートである。ブラウザは、まず、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｐｒｏｔｏｔｙｐｅ．ｏｐｅｎ関数として登録されている書換後ｏｐｅｎ関数を呼び出し、リクエスト先のＵＲＬを中継サーバ１０２を経由するＵＲＬに変更する（ステップ１９０１）。そして、保存されているｏｐｅｎ０（本来のｏｐｅｎ関数）を実行する（ステップ１９０２）。これにより、中継サーバ１０２に対してリクエストが送信される。

図２０は、ｄｏｃｕｍｅｎｔオブジェクトのｃｒｅａｔｅＥｌｅｍｅｎｔが実行されたときに行われるオブジェクト書換処理のフローチャートである。ブラウザは、まず、ｃｒｅａｔｅＥｌｅｍｅｎｔ０（本来のｃｒｅａｔｅＥｌｅｍｅｎｔ関数）を実行して、新たな要素を生成する（ステップ２００１）。そして、図２１に示すような要素別処理を行う（ステップ２００２）。

要素別処理では、ブラウザは、まず、生成された要素がａタグか否かをチェックし、その要素がａタグであれば、ａタグのクリックリスナを登録する（ステップ２１０４）。
生成された要素がａタグでなければ、次に、その要素がフォームか否かをチェックする（ステップ２１０２）。生成された要素がフォームであれば、フォームのｓｕｂｍｉｔ関数をｓｕｂｍｉｔ０として保存し（ステップ２１０５）、フォームのｓｕｂｍｉｔ関数を書換後ｓｕｂｍｉｔ関数に置き換える（ステップ２１０６）。

生成された要素がフォームでなければ、次に、その要素がボタンか否かをチェックする（ステップ２１０３）。生成された要素がボタンであれば、そのボタンのｔｙｐｅが“ｓｕｂｍｉｔ”か否かをチェックする（ステップ２１０７）。そして、ボタンのｔｙｐｅが“ｓｕｂｍｉｔ”であれば、そのボタンのクリックリスナとして書換後ｓｕｂｍｉｔ関数を登録する（ステップ２１０８）。

このような要素別処理によれば、生成された要素の種類に応じて、クリックリスナの追加やｓｕｂｍｉｔ関数の書換等の変更が行われ、その要素に基づくイベントが発生したときに、中継サーバ１０２に対してリクエストが送信されるようになる。

図２２は、ｄｏｃｕｍｅｎｔ．ｗｒｉｔｅ又はｉｎｎｅｒＨＴＭＬによりＷｅｂページ１１１が変更され、ＤＯＭ変更イベントが発生したときに行われるオブジェクト書換処理のフローチャートである。ブラウザは、まず、ＤＯＭイベントリスナとして登録されているＤＯＭ書換処理を実行して、生成された新たな要素を取得する（ステップ２２０１）。そして、図２１の要素別処理を行う（ステップ２２０２）。

図２３は、図１６のステップ１６０１で登録された監視処理のフローチャートである。ブラウザは、まず、ｃｈｅｃｋ関数を用いて、変更イベントによりＤＯＭ要素が生成された否かをチェックする（ステップ２３０１）。ＤＯＭ要素が生成されると、生成されたＤＯＭ要素を取得し（ステップ２３０２）、各ＤＯＭ要素について図２１の要素別処理を行う（ステップ２３０３）。

図１のクライアント端末１０１、中継サーバ１０２、及び元サーバ１０３は、例えば、図２４に示すような情報処理装置（コンピュータ）を用いて構成される。図２４の情報処理装置は、ＣＰＵ２４０１、メモリ２４０２、入力装置２４０３、出力装置２４０４、外部記憶装置２４０５、媒体駆動装置２４０６、およびネットワーク接続装置２４０７を備え、それらはバス２４０８により互いに接続されている。

メモリ２４０２は、例えば、Read Only Memory（ＲＯＭ）、Random Access Memory（ＲＡＭ）等を含み、処理に用いられるプログラムおよびデータを格納する。メモリ２４０２に格納されるプログラムには、ブラウザ及び書換スクリプト１１２が含まれ、メモリ２４０２に格納されるデータには、Ｗｅｂページ１１１のＨＴＭＬ文書が含まれる。ＣＰＵ２４０１は、メモリ２４０２を利用してプログラムを実行することにより、クライアント端末１０１、中継サーバ１０２、及び元サーバ１０３の処理を行う。

入力装置２４０３は、例えば、キーボード、ポインティングデバイス等であり、オペレータ又はユーザからの指示や情報の入力に用いられる。出力装置２４０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータ又はユーザへの問い合わせや処理結果の出力に用いられる。

外部記憶装置２４０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置２４０５に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ２４０２にロードして使用する。

媒体駆動装置２４０６は、可搬記録媒体２４０９を駆動し、その記録内容にアクセスする。可搬記録媒体２４０９は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータ又はユーザは、この可搬記録媒体２４０９にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ２４０２にロードして使用する。

ネットワーク接続装置２４０７は、インターネット等の通信ネットワークに接続され、通信に伴うデータ変換を行う。また、情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置２４０７を介して受け取り、それらをメモリ２４０２にロードして使用する。

図２５は、図２４の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体２４０９や外部装置２５０１のデータベース２５１１に格納されたプログラムおよびデータは、情報処理装置２５０２のメモリ２４０２にロードされる。外部装置２５０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、通信ネットワーク上の任意の伝送媒体を介して情報処理装置２５０２に送信する。ＣＰＵ２４０１は、そのデータを用いてそのプログラムを実行し、上述した処理を行う。

以上、図１から図２５までを参照しながら説明した実施形態に関し、さらに以下の付記を開示する。
（付記１）元サーバのページ情報をクライアントコンピュータに転送する中継サーバから該クライアントコンピュータに、該ページ情報とともに送信されるプログラムであって、
前記クライアントコンピュータが前記ページ情報の記述に基づき前記元サーバへのリクエストを送信するとき、該リクエストに含まれるユニフォームリソースロケータ情報中の該元サーバのサーバ名を前記中継サーバのサーバ名に変更するように、該ページ情報を書き換える処理を前記クライアントコンピュータに実行させることを特徴とするプログラム。
（付記２）前記クライアントコンピュータが前記ページ情報の記述に基づき前記元サーバへのリクエストを生成するための新たな要素情報を生成したとき、該要素情報に基づいて生成されるリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更するための書換情報を、該ページ情報に追加する処理を前記クライアントコンピュータにさらに実行させることを特徴とする付記１記
載のプログラム。
（付記３）前記クライアントコンピュータは、前記新たな要素情報がａタグである場合、該ａタグがクリックされたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報を変更するための書換情報を前記ページ情報に追加し、前記新たな要素情報がフォームである場合、該フォームのｓｕｂｍｉｔ関数が実行されたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報を変更するための書換情報を前記ページ情報に追加し、前記新たな要素情報がｓｕｂｍｉｔボタンである場合、該ｓｕｂｍｉｔボタンがクリックされたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報を変更するための書換情報を前記ページ情報に追加することを特徴とする付記２記載のプログラム。
（付記４）前記クライアントコンピュータは、前記ページ情報に含まれるフォームのｓｕｂｍｉｔ関数が実行されたとき、又は該フォームのｓｕｂｍｉｔボタンがクリックされたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更することを特徴とする付記１又は２記載のプログラム。
（付記５）前記クライアントコンピュータは、前記ページ情報に含まれるａタグがクリックされたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更することを特徴とする付記１又は２記載のプログラム。
（付記６）前記クライアントコンピュータは、前記ページ情報に含まれるｉｍｇタグのｓｒｃ属性、ｌｉｎｋタグのｈｒｅｆ属性、又はｓｃｒｉｐｔタグのｓｒｃ属性に記述されたユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更することを特徴とする付記１又は２記載のプログラム。
（付記７）前記クライアントコンピュータは、前記ページ情報に含まれるＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトのｏｐｅｎ関数が実行されたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更することを特徴とする付記１又は２記載のプログラム。
（付記８）元サーバのページ情報と書換プログラムを中継サーバから受信し、
前記書換プログラムを実行することで、ユニフォームリソースロケータ情報中の前記元サーバのサーバ名が前記中継サーバのサーバ名に変更されるように、該ページ情報を書き換え、
前記ページ情報の記述に基づき前記元サーバへのリクエストを生成し、
前記リクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更し、
変更後のユニフォームリソースロケータ情報に基づいて前記リクエストを前記中継サーバに送信する
ことを特徴とするリクエスト送信方法。
（付記９）元サーバのページ情報と書換プログラムを中継サーバから受信する受信手段と、
前記書換プログラムを実行することで、ユニフォームリソースロケータ情報中の前記元サーバのサーバ名が前記中継サーバのサーバ名に変更されるように、該ページ情報を書き換える書換手段と、
前記ページ情報の記述に基づき前記元サーバへのリクエストを送信するとき、該リクエストに含まれるユニフォームリソースロケータ情報中の該元サーバのサーバ名を前記中継サーバのサーバ名に変更する変更手段と、
変更後のユニフォームリソースロケータ情報に基づいて前記リクエストを前記中継サーバに送信する送信手段と
を備えることを特徴とする情報処理装置。

ＵＲＬ書換システムの構成図である。 ブラウザの基本動作を示す図である。 第１のリクエスト送信動作を示す図である。 第２のリクエスト送信動作を示す図である。 第３のリクエスト送信動作を示す図である。 第４のリクエスト送信動作を示す図である。 Ｗｅｂページを示す図である。 書換スクリプトを示す図である。 初期化処理のフローチャートである。 フォーム書換処理のフローチャートである。 ｓｕｂｍｉｔボタン書換処理のフローチャートである。 ａタグ書換処理のフローチャートである。 ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ書換処理のフローチャートである。 ＤＯＭ ＡＰＩ書換処理のフローチャートである。 ＤＯＭイベント登録処理のフローチャートである。 ｓｅｔＩｎｔｅｒｖａｌ登録処理のフローチャートである。 第１の送信処理のフローチャートである。 第２の送信処理のフローチャートである。 第３の送信処理のフローチャートである。 第１のオブジェクト書換処理のフローチャートである。 要素別処理のフローチャートである。 第２のオブジェクト書換処理のフローチャートである。 監視処理のフローチャートである。 情報処理装置の構成図である。 プログラムおよびデータの提供方法を示す図である。 従来のＵＲＬ書換方法を示す図である。

符号の説明

１１、１０１ クライアント端末
１２、１０２ 中継サーバ
１３、１０３ 元サーバ
２１ 書換済みＷｅｂページ
２２、１１１ Ｗｅｂページ
３１、１２１ 送信部
３２、１２２ 読込部
３３ 書換部
３４ 解析部
１１２ 書換スクリプト
７０１、７０２、７０３ リクエスト
８０１、８０２、８０３ スクリプト部分
２４０２ メモリ
２４０３ 入力装置
２４０４ 出力装置
２４０５ 外部記憶装置
２４０６ 媒体駆動装置
２４０７ ネットワーク接続装置
２４０８ バス
２５０１ 外部装置
２５０２ 情報処理装置
２５１１ データベース

Claims (5)

1. 元サーバのページ情報をクライアントコンピュータに転送する中継サーバから該クライアントコンピュータに、該ページ情報とともに送信されるプログラムであって、
   前記クライアントコンピュータが前記ページ情報の記述に基づき前記元サーバへの第１のリクエストを送信するとき、該第１のリクエストに含まれるユニフォームリソースロケータ情報中の該元サーバのサーバ名を前記中継サーバのサーバ名に変更するように、該ページ情報を書き換え、
   前記クライアントコンピュータが前記ページ情報の記述に基づき前記元サーバへの第２のリクエストを生成するための新たな要素情報を生成関数を用いて生成したとき、該要素情報に基づいて生成される第２のリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更するように、該生成関数を書き換えるための書換情報を、該ページ情報に追加する
   処理を前記クライアントコンピュータに実行させることを特徴とするプログラム。
2. 前記クライアントコンピュータは、前記新たな要素情報がａタグである場合、該ａタグがクリックされたときに生成される前記第２のリクエストに含まれるユニフォームリソースロケータ情報を変更するように前記生成関数を書き換えるための書換情報を前記ページ情報に追加し、前記新たな要素情報がフォームである場合、該フォームのｓｕｂｍｉｔ関数が実行されたときに生成される前記第２のリクエストに含まれるユニフォームリソースロケータ情報を変更するように前記生成関数を書き換えるための書換情報を前記ページ情報に追加し、前記新たな要素情報がｓｕｂｍｉｔボタンである場合、該ｓｕｂｍｉｔボタンがクリックされたときに生成される前記第２のリクエストに含まれるユニフォームリソースロケータ情報を変更するように前記生成関数を書き換えるための書換情報を前記ページ情報に追加することを特徴とする請求項１記載のプログラム。
3. 前記クライアントコンピュータは、前記ページ情報に含まれるＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトのｏｐｅｎ関数が実行されたときに生成されるリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更することを特徴とする請求項１又は２記載のプログラム。
4. 元サーバのページ情報と書換プログラムを中継サーバから受信し、
   前記書換プログラムを実行することで、ユニフォームリソースロケータ情報中の前記元サーバのサーバ名が前記中継サーバのサーバ名に変更されるように、該ページ情報を書き換え、
   前記ユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更するように生成関数を書き換えるための書換情報を、前記ページ情報に追加し、
   前記ページ情報の記述に基づき前記元サーバへの第１のリクエストを生成し、
   前記第１のリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更し、
   変更後のユニフォームリソースロケータ情報に基づいて前記第１のリクエストを前記中継サーバに送信し、
   前記ページ情報の記述に基づき前記元サーバへの第２のリクエストを生成するための新たな要素情報を前記生成関数を用いて生成し、
   前記第２のリクエストに含まれるユニフォームリソースロケータ情報中の前記元サーバのサーバ名を前記中継サーバのサーバ名に変更し、
   変更後のユニフォームリソースロケータ情報に基づいて前記第２のリクエストを前記中継サーバに送信する
   ことを特徴とするリクエスト送信方法。
5. 元サーバのページ情報と書換プログラムを中継サーバから受信する受信手段と、
   前記書換プログラムを実行することで、ユニフォームリソースロケータ情報中の前記元サーバのサーバ名が前記中継サーバのサーバ名に変更されるように、該ページ情報を書き換えるとともに、該ユニフォームリソースロケータ情報中の該元サーバのサーバ名が該中継サーバのサーバ名に変更されるように生成関数を書き換えるための書換情報を、該ページ情報に追加する書換手段と、
   前記ページ情報の記述に基づき前記元サーバへの第１のリクエストを送信するとき、該第１のリクエストに含まれるユニフォームリソースロケータ情報中の該元サーバのサーバ名を前記中継サーバのサーバ名に変更し、前記ページ情報の記述に基づき該元サーバへの第２のリクエストを生成するための新たな要素情報が前記生成関数を用いて生成されたとき、該第２のリクエストに含まれるユニフォームリソースロケータ情報中の該元サーバのサーバ名を該中継サーバのサーバ名に変更する変更手段と、
   変更後のユニフォームリソースロケータ情報に基づいて前記第１及び第２のリクエストを前記中継サーバに送信する送信手段と
   を備えることを特徴とする情報処理装置。

Images