JP4165018B2 - プロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラム - Google Patents
プロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラム Download PDFInfo
- Publication number
- JP4165018B2 JP4165018B2 JP2001030407A JP2001030407A JP4165018B2 JP 4165018 B2 JP4165018 B2 JP 4165018B2 JP 2001030407 A JP2001030407 A JP 2001030407A JP 2001030407 A JP2001030407 A JP 2001030407A JP 4165018 B2 JP4165018 B2 JP 4165018B2
- Authority
- JP
- Japan
- Prior art keywords
- page
- error
- client
- proxy server
- displayed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はプロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラムに関し、特にネットワークインターフェースを有するコンピュータシステムに用いるプロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラムに関する。
【０００２】
【従来の技術】
従来、ｗｗｗシステムにおけるプロキシサーバー（ｐｒｏｘｙ ｓｅｒｖｅｒ）はクライアントの代理としてｗｗｗサーバーへのＨＴＭＬ（ｈｙｐｅｒ ｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ページやＧＩＦ（ｇｒａｐｈｉｃｓ ｉｎｔｅｒｃｈａｎｇｅ ｆｏｒｍａｔ）等のオブジェクトの取得やレスポンス向上のために今まで取得したオブジェクトをローカルメモリやローカルＨＤＤ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ）等にキャッシングする処理等がメインの処理であった。
【０００３】
クライアントが所望のページ取得の際に、対象となるページが置かれているサーバーで何かしらトラブルが発生した場合には、そのｗｗｗサーバーはエラーに応じたエラーコードだけを返したり、エラーコードに応じたエラー内容を表すページを付加して返答を返したりしている。この場合、従来のプロキシサーバーでは、サーバーから送られてきたエラー内容の応答をそのままクライアントへ中継しているだけであった。
【０００４】
また、ｗｗｗサーバーへ接続できない、ｗｗｗサーバーから応答が無い、等のプロキシサーバーが検出できるエラーの場合には、プロキシサーバーがｗｗｗサーバーに変わってエラーコードとそのエラー内容を説明する応答ページをクライアントへ返送している。その応答ページには、クライアントからの要求オブジェクトの再取得を促す目的で、その要求をアンカーに埋め込む処理を行っているプロキシサーバーも見受けられる。これは、ページの取得を一番重要視するポリシーの実装である。
【０００５】
【発明が解決しようとする課題】
上記の様に、プロキシサーバーがｗｗｗサーバーからのエラー応答を単純に中継したり、プロキシサーバーが要求ＵＲＬを応答ページのアンカーとして埋め込んだりした場合には、次のページの取得ができないと、ページを表示するブラウザのページバック機能を使わなければエラー状態から抜け出すことができない。
【０００６】
ｗｗｗ技術をベースとしたシステムには、例えば、タッチパネルだけを入力手段としているページバック機能を持たないＷＥＢ専用端末を用いて構築されたものもある。このようなｗｗｗベースのシステムにおいては、上記のようなエラーが発生し、図８に示されているようなページが出現した時点で、ｗｗｗベースで提供するサービスも中断してしまう。同図においては、「ＨＴＴＰ／１．０ ４０４オブジェクトが見つかりません」というメッセージが画面に表示されている。
【０００７】
タッチパネルしか入力する手段を持たないＷＥＢ専用端末において、このエラー状況から復旧するには、主電源を一旦切断し、再度投入することが唯一の手段となる。これではサービスを安定して提供することができないという欠点があった。
また、従来のプロキシサーバーでは、クライアントが取得要求するオブジェクトが正しく存在したり、要求するオブジェクトを有するサーバーが正常に動作している間は問題ない。しかしながら、サーバーは取得要求対象のオブジェクトを返すことができない状態になったり、エラー等が発生した場合には、従来のプロキシサーバーでは、エラーコードとともに、エラー発生を示す簡素なＨＴＭＬページを返している。
【０００８】
ｗｗｗ技術をベースとした上記のようなシステムを構築する場合には、ユーザにページを順番に閲覧させることでサービスを提供している。しかしながら、従来のプロキシサーバーでは、一旦上記のエラー等が発生すると一連のページ閲覧ができなくなり、結果的に、サービスが中断してしまう。
このような状況から抜け出すためには、端末側でエラーが起きる前のページへ飛ぶか、前のページに戻る機能が無い専用端末を使った場合には電源の再投入をすることになる。これではサービスを安定して提供することができないという欠点がある。
【０００９】
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的はサービスを安定して提供することのできるプロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラムを提供することである。
【００１０】
【課題を解決するための手段】
本発明によるプロキシサーバーは、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーであって、前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出手段と、前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出手段がエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成手段と、このページ生成手段によって生成したページを前記クライアントに送出するページ送出手段と、を含むことを特徴とする。
なお、上記プロキシサーバーにおいて、前記エラーページ検出手段は、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする。
【００１２】
本発明によるプロキシサーバー制御方法は、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であって、前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出ステップにおいてエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成ステップと、このページ生成ステップにおいて生成したページを前記クライアントに送出するページ送出ステップと、を含むことを特徴とする。
【００１４】
なお、上記プロキシサーバー制御方法において、前記エラーページ検出ステップにおいては、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする。
本発明によるプログラムは、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御するプログラムであって、前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出ステップにおいてエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成ステップと、このページ生成ステップにおいて生成したページを前記クライアントに送出するページ送出ステップと、を含むことを特徴とする。
【００１６】
なお、上記プログラムにおいて、前記エラーページ検出ステップにおいては、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする。
先に述べたように、ｗｗｗサーバー側でエラー等がおきることによって一連のページ閲覧によって成されていたサービスの中断が起きる。
【００１７】
特に、前のページに戻る機能を持たない専用端末をクライアントとして使用していた場合には、専用端末の電源を再投入するしか復旧する手段が無い。この問題を回避するには、常時サーバーから返されるクライアントへのＨＴＴＰの応答ステータスコードを監視してエラーコードが検出された場合には、エラーコードの他にエラー内容を説明する応答ページに直前のページを自動で取得できるタグを埋め込むことで、自動的に前のページに戻ることが可能となる。
【００１８】
これによって、エラーの前のページに戻る機能を持たない専用端末であっても、一連のページ閲覧の中断による影響を最小限に押されることが可能となり、サービスの低下も防ぐことができる。
【００１９】
要するに、本システムでは、応答ページに自動でページバックを挿入することにより、サービスを安定して提供することができるのである。
【００２０】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
図１は本発明によるプロキシサーバーの第１の実施形態を示すブロック図である。同図に示されているように、本実施形態によるプロキシサーバーは、クライアント（図示せず）からのコマンドの解析等を行うコマンド処理部１と、ＨＴＴＰヘッダの解析等を行うデータ受信部２と、クライアントに対して各種のデータを転送するページ中継部３と、ＨＴＴＰヘッダを生成するＨＴＴＰヘッダ作成部４と、自動ページバックタグを生成する自動タグ生成部５とを含んで構成されている。
【００２１】
コマンド処理部１では、クライアントからのコマンドを解析する。受信したＨＴＴＰコマンドを解析することで、現在の要求ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）が記述されているページ情報を取り出し、それを保存する。
データ受信部２はｗｗｗサーバー（図示せず）から送られてくるＨＴＴＰヘッダの解析を行う。データ受信部２は、この解析によって取得したステータスコードと応答ページデータとをページ中継部３へ渡す。また、受信したＨＴＴＰヘッダデータ全てをＨＴＴＰヘッダ作成部４へ渡す。
【００２２】
ページ中継部３は受け取ったステータスコードが正常であればＨＴＴＰヘッダ作成部４が持っているＨＴＴＰヘッダをそのままクライアントへ転送する。また応答データもそのまま転送する。ページ中継部３は受け取ったステータスコードにエラーが検出されると、ＨＴＴＰヘッダ作成部４に対して新しいＨＴＴＰヘッダの生成を依頼し、生成された新しいＨＴＴＰヘッダをクライアントへ送り返す。
【００２３】
また、ページ中継部３はコマンド処理部で保存されているページ情報を取り出し、自動タグ生成部５へ渡し、自動タグ生成部５で生成されたデータを応答ページデータへ埋め込んだ後に、クライアントへ転送する。
かかる構成において、コマンド処理部１では、クライアントからのコマンドを解析する。ｗｗｗサーバーのアドレスやＨＴＴＰコマンド、ＵＲＬの取り出しならびに現在の要求ＵＲＬが記述されているページ情報を取り出し、それを保存する。そして、取り出したサーバーアドレスを基にｗｗｗサーバーへ接続し、ＨＴＴＰコマンドをｗｗｗサーバーへ送る。
【００２４】
データ受信部２はｗｗｗサーバーから送られてくるデータを受信しながら、ＨＴＴＰヘッダと応答ページとの分離作業を行う。すなわち、データを受信しながら、そのデータに含まれているＨＴＴＰヘッダ部分を取出す。この分離が終わると、データ受信部２はＨＴＴＰヘッダから応答ステータスコードの取り出しを行う。応答ステータスコードの取り出しが終わったら、データ受信部２は取り出したステータスコードと応答データとをページ中継部３へ渡し、ＨＴＴＰヘッダデータはＨＴＴＰヘッダ作成部４へ渡す。
【００２５】
ここまでの処理で、ｗｗｗサーバーからの応答にエラーがあるか無いかの判断が可能になる。エラーがなければ、ｗｗｗサーバーから受信したデータをそのままクライアントへ転送する。
エラーが検出された場合には,応答ページに自動ページバックのタグを挿入するために応答ページの大きさが変わる。その変更をＨＴＴＰヘッダに入れ込む必要があるのでＨＴＴＰヘッダ作成部４で、ＨＴＴＰヘッダの作り直しを行う。
【００２６】
挿入する自動ページタグの作成は、自動タグ生成部５に、コマンド処理部１に保存してあるページ情報を渡して生成させる。
自動タグ生成部５で作成するデータはコマンド処理部で保存してある ページ情報文字列をRefererとすると下記の書式で構成される文字列データである。
【００２７】
なお、上記の「１０」は１０秒を意味し、その応答ページを受信して１０秒経過したらＵＲＬ＝“Referer”で指定されるオブジェクトを取得することとなる。この秒数は、システムの種類に応じて他の値に変えたい場合もあり、上記の数値「１０」に限定されず、任意に変えることができるものとする。
【００２８】
この文字列データの長さをＨＴＴＰヘッダ作成部４に与えることでＨＴＴＰ作成部に新しいＨＴＴＰヘッダを生成させる。ページ中継部３は上記フォーマットの文字列データを保持している応答ページデータを先頭に挿入し、クライアントへ送り返す。
以上の動作について、図２を参照して説明する。同図において、クライアントからの要求コマンドを受信すると（ステップＳ２０１）、その受信した要求コマンドを解析する（ステップＳ２０２）。このとき、接続先サーバー情報の取得と保存、取得ＵＲＬ情報の取得と保存、現在のページ情報の取得と保存、を行う。
【００２９】
次に、エラーが発生しているかエラー検査を行う（ステップＳ２０３）。エラーを検出しなければ、サーバーへの接続処理を行う（ステップＳ２０４）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ２０５）。エラーを検出しなければ、サーバーへコマンドを送信する（ステップＳ２０６）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ２０７）。エラーを検出しなければ、サーバーからＨＴＴＰヘッダを受信する（ステップＳ２０８）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ２０９）。エラーを検出しなければ、ＨＴＴＰヘッダを解析する（ステップＳ２１０）。この場合、ＨＴＴＰステータスコードを取得する。その後、ステータスコードを検査する（ステップＳ２１２）。
【００３０】
ステップＳ２０３、Ｓ２０５、Ｓ２０７、Ｓ２０９のいずれかにおいて、エラーを検出した場合は、内部エラーページを作成する（ステップＳ２１１）。この場合、ＨＴＴＰヘッダを作成し、内部エラーページを作成する。その後、ステータスコードを検査する（ステップＳ２１２）。
ステータスコードの検査においては、ステータスコードが４００番台であるか、又は５００番台であるかが確認される。４００番台及び５００番台のステータスコードは、エラーの発生を示すエラーコードだからである。
【００３１】
ステータスコードを検査した結果、エラーを検出すれば、自動ページバックタグ文字列を作成する（ステップＳ２１２→Ｓ２１３）。例えば、
とする。
【００３２】
次に、ページバックアンカー文字列を作成する（ステップＳ２１４）。例えば、
＜Ａ ＨＲＥＦ＝“ｈｔｔｐ：／／ｘｘｘｘｘｘｘｘ”＞Ｂａｃｋ＜／Ａ＞
とする。
作成した文字列長を元に、新しいＨＴＴＰヘッダを作成し直す（ステップＳ２１５）。この場合、ＨＴＴＰヘッダには応答ページ長があるので、それを修正する。作成した２つの文字列を応答ページに挿入して、新しい応答ページを作成し直す（ステップＳ２１６）。そして、ステップＳ２１５において作成した新しいＨＴＴＰヘッダをクライアントへ送る（ステップＳ２１７）。さらに、ステップＳ２１６において作成した新しい応答ページをクライアントへ送る（ステップＳ２１８）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ２１９）。以上で処理が終了となる。
【００３３】
一方、ステップＳ２１２において、エラーがなければＨＴＴＰヘッダをクライアントへ送る（ステップＳ２１２→Ｓ２２０）。そして、応答ページをクライアントへ送る（ステップＳ２２１）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ２１９）。以上で処理が終了となる。
以上の処理を行うことにより、エラーが発生すると、以下の表示が行われる。例えば、ファミリーレストランにおいて本システムを導入すると、最初の表示画面には、図３に示されているように、サービスメニューとして「情報サービス」として「交通情報」、「エリアガイド」及び「天気予報」、飲食の「メニュー」として「主食」、「セットメニュー」、「子供メニュー」、「ドリンク」及び「デザート」、「その他のサービス」として「御会計」及び「店員呼び出し」が表示される。ユーザがこの表示画面中の任意のメニューを選択すべく、アンカーが表示されているタッチパネルの表面を押すと、通常はそのリンク先の画面が表示される。
【００３４】
しかしながら、エラーが発生すると、図４に示されているように、「エラー発生を検出しました。暫くすると、直前のページに戻ります。もう一度トライしてもダメな場合は、御手数ですが、店員へ連絡してください。」及び「ＨＴＴＰ／１．０ ４０４オブジェクトが見つかりません」というメッセージと共に、「手動強制ページバック」という文字列のアンカーが画面に表示される。
【００３５】
上述した従来のシステムにおいては、図８に示されているようにエラーの発生の旨を伝えるだけの画面が表示されるにすぎないので、主電源を再投入して復旧させるしか手段がなかった。これに対し、本システムでは「手動強制ページバック」という文字列のアンカーが表示されているタッチパネルの表面を押すことによって、強制的に直前のページに戻ることができる。
【００３６】
以上説明した第１の実施形態においては、以下のようなプロキシサーバーの制御方法が実現されていることになる。すなわち、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であり、上記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、このエラーページ検出ステップにおいてエラーページを検出したときそのエラーを回避することのできるページを生成するページ生成ステップと、このページ生成ステップにおいて生成したページを上記クライアントに送出するページ送出ステップとを含む制御方法が実現されていることになる。そして、上記ページ生成ステップにおいては、上記エラーページ検出ステップにおいてエラーページを検出したとき直前のページに戻るためのタグを生成し、上記ページ送出ステップにおいては、生成した上記タグを有するページを上記クライアントに送出している。
【００３７】
さらに、図２等に示されている動作を実現するためのプログラムを用意し、これを用いてコンピュータを制御すれば、上述と同様の処理を行うことができることは明白である。このプログラムを記録するための記録媒体には、図１等に示されていない半導体メモリ、磁気ディスク、光ディスク等の他、種々の記録媒体を用いることができる。
【００３８】
なお、上記はファミリーレストランにおいてユーザが操作する端末を含むシステムを例として説明したが、その場合に限らず種々端末を用いるシステムについて本発明が適用できることは明らかである。
図５は本発明によるプロキシサーバーの第２の実施形態を示すブロック図である。同図に示されているように、本実施形態によるプロキシサーバーは、クライアント（図示せず）からのコマンドの解析等を行うコマンド処理部１と、ＨＴＴＰヘッダの解析等を行うデータ受信部２と、エラーページを送出するエラーページ送出部６と、ＨＴＴＰヘッダ作成部ＨＴＴＰヘッダ作成部４と、差し換えページを作成する差し換えページ生成部７とを含んで構成されている。
【００３９】
かかる構成において、コマンド処理部１はクライアントからのコマンドの解析と処理を行う。この処理でエラーを検出した場合には、応答ページ処理へエラー内容の通知を行う。エラーが無ければｗｗｗサーバー（図示せず）ヘコマンドを送る。
データ受信部２はｗｗｗサーバーから送られてくるＨＴＴＰヘッダの解析を行う。この解析において、ステータスコードにエラーコードを検出した場合には、エラーページ送出部６へエラーコードを渡す。
【００４０】
エラーページ送出部６は受け取ったエラーコードを、ＨＴＴＰヘッダ作成部４に渡す。ＨＴＴＰヘッダ作成部４では、新しいＨＴＴＰヘッダを作成して、エラーページ送出部６に渡す。また、エラーページ送出部６は受け取ったエラーコードを、差し換えページ生成部７へ渡す。差し換えページ生成部７は差し換えるべき応答ページを探し出し、エラーページ送出部６へ渡す。
【００４１】
エラーページ送出部６は、新しいＨＴＴＰヘッダと、差し換え応答ページとをクライアントへ送り返す。
データ受信部２は、ｗｗｗサーバーから送られてくるＨＴＴＰヘッダに含まれている応答ステータスコードを取り出し、エラー状態を示す、４００番台、５００番台のエラーコードかどうかの検査を絶えず行っている。検査の結果、応答ステータスコードが４００番台、５００番台を検出した場合には、ｗｗｗサーバーで何かしらのエラーが起きていることが判るので、プロキシサーバーは応答ページを差し換えすべき状態を検出できる。
【００４２】
ここで、差し換えるページの特定方法には、種々の方法が考えられる。すなわち、例えば差し換えページの格納ディレクトリを指定しておき、
「error」＋「３桁の数字」＋「.htm」
からなるファイル名の生成規則を仮定する。そして、３桁の数字が一致するファイルがある場合にはそのファイルを差し換えファイルとしてクライアントへ返す。一方、もしそのファイルが見つからなければ、デフォルトの処理を定義した差し換えページを指定する。
【００４３】
以上の動作について、図６を参照して説明する。同図において、クライアントからの要求コマンドを受信すると（ステップＳ６０１）、その受信した要求コマンドを解析する（ステップＳ６０２）。このとき、接続先サーバー情報の取得と保存、取得ＵＲＬ情報の取得と保存、現在のページ情報の取得と保存、を行う。次に、エラーが発生しているかエラー検査を行う（ステップＳ６０３）。エラーを検出しなければ、サーバーへの接続処理を行う（ステップＳ６０４）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ６０５）。エラーを検出しなければ、サーバーへコマンドを送信する（ステップＳ６０６）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ６０７）。エラーを検出しなければ、サーバーからＨＴＴＰヘッダを受信する（ステップＳ６０８）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ６０９）。エラーを検出しなければ、ＨＴＴＰヘッダを解析する（ステップＳ６１０）。この場合、ＨＴＴＰステータスコードを取得する。その後、ステータスコードを検査する（ステップＳ６１２）。
【００４４】
ステップＳ６０３、Ｓ６０５、Ｓ６０７、Ｓ６０９のいずれかにおいて、エラーを検出した場合は、内部エラーページを作成する（ステップＳ６１１）。この場合、ＨＴＴＰヘッダを作成し、内部エラーページを作成する。その後、ステータスコードを検査する（ステップＳ６１２）。
ステータスコードの検査においては、ステータスコードが４００番台であるか、又は５００番台であるかが確認される。ステータスコードを検査した結果、エラーを検出すれば、差し換えページの検索が行われる（ステップＳ６１２→Ｓ６１３）。この場合、ステータスコードに応じた差し換えページがあるか判断される。差し換えページが検出できれば、新しいＨＴＴＰヘッダを作成する（ステップＳ６１３→Ｓ６１４）。この場合、差し換えページ長を元に、新しいＨＴＴＰヘッダを作成し直す。
【００４５】
次に、作成した新しいＨＴＴＰヘッダをクライアントへ送る（ステップＳ６１５）。そして、差し換えする応答ページをクライアントへ送る（ステップＳ６１６）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ６１７）。以上で処理が終了となる。
一方、ステップＳ６１２において、エラーがなければＨＴＴＰヘッダをクライアントへ送る（ステップＳ６１８）。そして、応答ページをクライアントへ送る（ステップＳ６１９）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ６１７）。以上で処理が終了となる。
【００４６】
また、ステップＳ６１３において、差し換えページを検索したが、差し換えページのファイルが見つからない場合、ＨＴＴＰヘッダをクライアントへ送る（ステップＳ６１８）。そして、応答ページをクライアントへ送る（ステップＳ６１９）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ６１７）。以上で処理が終了となる。
【００４７】
以上の処理を行うことにより、エラーが発生すると、以下の表示が行われる。例えば、ファミリーレストランにおいて本システムを導入すると、最初の表示画面には、図３に示されているように、サービスメニューとして「情報サービス」として「交通情報」、「エリアガイド」及び「天気予報」、飲食の「メニュー」として「主食」、「セットメニュー」、「子供メニュー」、「ドリンク」及び「デザート」、「その他のサービス」として「御会計」及び「店員呼び出し」が表示される。ユーザがこの表示画面中の任意のメニューを選択すべく、アンカーが表示されているタッチパネルの表面を押すと、通常はそのリンク先の画面が表示される。
【００４８】
しかしながら、エラーが発生すると、図７に示されているように、「ちょっとお待ちください」及び「サーバーの調子が良くありません。御手数ですが、下記のいずれかの処理を御選びください。」というメッセージの他に、「トップページへ戻る」、「もう一度リトライしてみる」及び「サーバー不調を店員へ連絡」という各文字列のアンカーが画面に表示される。このような表示画面を見たユーザは、「トップページへ戻る」、「もう一度リトライしてみる」、「サーバー不調を店員へ連絡」、のいずれかのアンカーを選択し、そのアンカーが表示されているタッチパネルの表面を押すことになる。こうすれば、サービスを中断させることはない。
【００４９】
上述した従来のシステムにおいては、図８に示されているようにエラーの発生の旨を伝えるだけの画面が表示されるにすぎない。つまり、サービスが中断し、エラーそのものをユーザに見せてしまうことになる。また、この画面から復旧させるには主電源を再投入するしか手段がない。
これに対し、本システムでは差し換えるページをエラー内容に応じて予め指定しておき、図８に示されているようなエラーページがｗｗｗサーバーから送られてきたことを検出したとき、図７に示されているようなページを画面に表示することにより、ユーザに違和感を与えずにサービスを安定して提供することができる。
【００５０】
以上説明した第２の実施形態においては、以下のようなプロキシサーバーの制御方法が実現されていることになる。すなわち、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であり、エラー発生の旨を表示するエラーページの代わりに上記クライアントに送出すべき差し換えページを生成するページ生成ステップと、上記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、このエラーページ検出ステップがエラーページを検出したとき該エラーページの代わりに上記ページ生成ステップにおいて生成した差し換えページを上記クライアントに送出するページ送出ステップとを含む制御方法が実現されている。
【００５１】
さらに、図６等に示されている動作を実現するためのプログラムを用意し、これを用いてコンピュータを制御すれば、上述と同様の処理を行うことができることは明白である。このプログラムを記録するための記録媒体には、図５等に示されていない半導体メモリ、磁気ディスク、光ディスク等の他、種々の記録媒体を用いることができる。
【００５２】
なお、上記はファミリーレストランにおいてユーザが操作する端末を含むシステムを例として説明したが、その場合に限らず種々端末を用いるシステムについて本発明が適用できることは明らかである。
【００５３】
【発明の効果】
以上説明したように本発明は、自動的に直前のページに戻るタグを挿入することにより、前のページに戻る機能を持っていないＷＥＢ端末を用いても、エラー応答ページがプロキシサーバーを経由してクライアントへ送り返される時に、直前のページに戻ることができるので、ページ閲覧の中断が回避され、サービスの中断を回避できるという効果がある。
【図面の簡単な説明】
【図１】本発明によるプロキシサーバーの実施の第１の形態を示すブロック図である。
【図２】図１のプロキシサーバーの動作を示すフローチャートである。
【図３】表示画面の例を示す図である。
【図４】エラー発生時における表示画面の例を示す図である。
【図５】本発明によるプロキシサーバーの実施の第２の形態を示すブロック図である。
【図６】図５のプロキシサーバーの動作を示すフローチャートである。
【図７】エラー発生時における表示画面の例を示す図である。
【図８】エラー発生時における表示画面の従来例を示す図である。
【符号の説明】
１ コマンド処理部
２ データ受信部
３ ページ中継部
４ ＨＴＴＰヘッダ作成部
５ 自動タグ生成部
６ エラーページ送出部
７ 差し換えページ生成部
【発明の属する技術分野】
本発明はプロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラムに関し、特にネットワークインターフェースを有するコンピュータシステムに用いるプロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラムに関する。
【０００２】
【従来の技術】
従来、ｗｗｗシステムにおけるプロキシサーバー（ｐｒｏｘｙ ｓｅｒｖｅｒ）はクライアントの代理としてｗｗｗサーバーへのＨＴＭＬ（ｈｙｐｅｒ ｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ページやＧＩＦ（ｇｒａｐｈｉｃｓ ｉｎｔｅｒｃｈａｎｇｅ ｆｏｒｍａｔ）等のオブジェクトの取得やレスポンス向上のために今まで取得したオブジェクトをローカルメモリやローカルＨＤＤ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ）等にキャッシングする処理等がメインの処理であった。
【０００３】
クライアントが所望のページ取得の際に、対象となるページが置かれているサーバーで何かしらトラブルが発生した場合には、そのｗｗｗサーバーはエラーに応じたエラーコードだけを返したり、エラーコードに応じたエラー内容を表すページを付加して返答を返したりしている。この場合、従来のプロキシサーバーでは、サーバーから送られてきたエラー内容の応答をそのままクライアントへ中継しているだけであった。
【０００４】
また、ｗｗｗサーバーへ接続できない、ｗｗｗサーバーから応答が無い、等のプロキシサーバーが検出できるエラーの場合には、プロキシサーバーがｗｗｗサーバーに変わってエラーコードとそのエラー内容を説明する応答ページをクライアントへ返送している。その応答ページには、クライアントからの要求オブジェクトの再取得を促す目的で、その要求をアンカーに埋め込む処理を行っているプロキシサーバーも見受けられる。これは、ページの取得を一番重要視するポリシーの実装である。
【０００５】
【発明が解決しようとする課題】
上記の様に、プロキシサーバーがｗｗｗサーバーからのエラー応答を単純に中継したり、プロキシサーバーが要求ＵＲＬを応答ページのアンカーとして埋め込んだりした場合には、次のページの取得ができないと、ページを表示するブラウザのページバック機能を使わなければエラー状態から抜け出すことができない。
【０００６】
ｗｗｗ技術をベースとしたシステムには、例えば、タッチパネルだけを入力手段としているページバック機能を持たないＷＥＢ専用端末を用いて構築されたものもある。このようなｗｗｗベースのシステムにおいては、上記のようなエラーが発生し、図８に示されているようなページが出現した時点で、ｗｗｗベースで提供するサービスも中断してしまう。同図においては、「ＨＴＴＰ／１．０ ４０４オブジェクトが見つかりません」というメッセージが画面に表示されている。
【０００７】
タッチパネルしか入力する手段を持たないＷＥＢ専用端末において、このエラー状況から復旧するには、主電源を一旦切断し、再度投入することが唯一の手段となる。これではサービスを安定して提供することができないという欠点があった。
また、従来のプロキシサーバーでは、クライアントが取得要求するオブジェクトが正しく存在したり、要求するオブジェクトを有するサーバーが正常に動作している間は問題ない。しかしながら、サーバーは取得要求対象のオブジェクトを返すことができない状態になったり、エラー等が発生した場合には、従来のプロキシサーバーでは、エラーコードとともに、エラー発生を示す簡素なＨＴＭＬページを返している。
【０００８】
ｗｗｗ技術をベースとした上記のようなシステムを構築する場合には、ユーザにページを順番に閲覧させることでサービスを提供している。しかしながら、従来のプロキシサーバーでは、一旦上記のエラー等が発生すると一連のページ閲覧ができなくなり、結果的に、サービスが中断してしまう。
このような状況から抜け出すためには、端末側でエラーが起きる前のページへ飛ぶか、前のページに戻る機能が無い専用端末を使った場合には電源の再投入をすることになる。これではサービスを安定して提供することができないという欠点がある。
【０００９】
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的はサービスを安定して提供することのできるプロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラムを提供することである。
【００１０】
【課題を解決するための手段】
本発明によるプロキシサーバーは、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーであって、前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出手段と、前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出手段がエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成手段と、このページ生成手段によって生成したページを前記クライアントに送出するページ送出手段と、を含むことを特徴とする。
なお、上記プロキシサーバーにおいて、前記エラーページ検出手段は、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする。
【００１２】
本発明によるプロキシサーバー制御方法は、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であって、前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出ステップにおいてエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成ステップと、このページ生成ステップにおいて生成したページを前記クライアントに送出するページ送出ステップと、を含むことを特徴とする。
【００１４】
なお、上記プロキシサーバー制御方法において、前記エラーページ検出ステップにおいては、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする。
本発明によるプログラムは、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御するプログラムであって、前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出ステップにおいてエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成ステップと、このページ生成ステップにおいて生成したページを前記クライアントに送出するページ送出ステップと、を含むことを特徴とする。
【００１６】
なお、上記プログラムにおいて、前記エラーページ検出ステップにおいては、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする。
先に述べたように、ｗｗｗサーバー側でエラー等がおきることによって一連のページ閲覧によって成されていたサービスの中断が起きる。
【００１７】
特に、前のページに戻る機能を持たない専用端末をクライアントとして使用していた場合には、専用端末の電源を再投入するしか復旧する手段が無い。この問題を回避するには、常時サーバーから返されるクライアントへのＨＴＴＰの応答ステータスコードを監視してエラーコードが検出された場合には、エラーコードの他にエラー内容を説明する応答ページに直前のページを自動で取得できるタグを埋め込むことで、自動的に前のページに戻ることが可能となる。
【００１８】
これによって、エラーの前のページに戻る機能を持たない専用端末であっても、一連のページ閲覧の中断による影響を最小限に押されることが可能となり、サービスの低下も防ぐことができる。
【００１９】
要するに、本システムでは、応答ページに自動でページバックを挿入することにより、サービスを安定して提供することができるのである。
【００２０】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
図１は本発明によるプロキシサーバーの第１の実施形態を示すブロック図である。同図に示されているように、本実施形態によるプロキシサーバーは、クライアント（図示せず）からのコマンドの解析等を行うコマンド処理部１と、ＨＴＴＰヘッダの解析等を行うデータ受信部２と、クライアントに対して各種のデータを転送するページ中継部３と、ＨＴＴＰヘッダを生成するＨＴＴＰヘッダ作成部４と、自動ページバックタグを生成する自動タグ生成部５とを含んで構成されている。
【００２１】
コマンド処理部１では、クライアントからのコマンドを解析する。受信したＨＴＴＰコマンドを解析することで、現在の要求ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）が記述されているページ情報を取り出し、それを保存する。
データ受信部２はｗｗｗサーバー（図示せず）から送られてくるＨＴＴＰヘッダの解析を行う。データ受信部２は、この解析によって取得したステータスコードと応答ページデータとをページ中継部３へ渡す。また、受信したＨＴＴＰヘッダデータ全てをＨＴＴＰヘッダ作成部４へ渡す。
【００２２】
ページ中継部３は受け取ったステータスコードが正常であればＨＴＴＰヘッダ作成部４が持っているＨＴＴＰヘッダをそのままクライアントへ転送する。また応答データもそのまま転送する。ページ中継部３は受け取ったステータスコードにエラーが検出されると、ＨＴＴＰヘッダ作成部４に対して新しいＨＴＴＰヘッダの生成を依頼し、生成された新しいＨＴＴＰヘッダをクライアントへ送り返す。
【００２３】
また、ページ中継部３はコマンド処理部で保存されているページ情報を取り出し、自動タグ生成部５へ渡し、自動タグ生成部５で生成されたデータを応答ページデータへ埋め込んだ後に、クライアントへ転送する。
かかる構成において、コマンド処理部１では、クライアントからのコマンドを解析する。ｗｗｗサーバーのアドレスやＨＴＴＰコマンド、ＵＲＬの取り出しならびに現在の要求ＵＲＬが記述されているページ情報を取り出し、それを保存する。そして、取り出したサーバーアドレスを基にｗｗｗサーバーへ接続し、ＨＴＴＰコマンドをｗｗｗサーバーへ送る。
【００２４】
データ受信部２はｗｗｗサーバーから送られてくるデータを受信しながら、ＨＴＴＰヘッダと応答ページとの分離作業を行う。すなわち、データを受信しながら、そのデータに含まれているＨＴＴＰヘッダ部分を取出す。この分離が終わると、データ受信部２はＨＴＴＰヘッダから応答ステータスコードの取り出しを行う。応答ステータスコードの取り出しが終わったら、データ受信部２は取り出したステータスコードと応答データとをページ中継部３へ渡し、ＨＴＴＰヘッダデータはＨＴＴＰヘッダ作成部４へ渡す。
【００２５】
ここまでの処理で、ｗｗｗサーバーからの応答にエラーがあるか無いかの判断が可能になる。エラーがなければ、ｗｗｗサーバーから受信したデータをそのままクライアントへ転送する。
エラーが検出された場合には,応答ページに自動ページバックのタグを挿入するために応答ページの大きさが変わる。その変更をＨＴＴＰヘッダに入れ込む必要があるのでＨＴＴＰヘッダ作成部４で、ＨＴＴＰヘッダの作り直しを行う。
【００２６】
挿入する自動ページタグの作成は、自動タグ生成部５に、コマンド処理部１に保存してあるページ情報を渡して生成させる。
自動タグ生成部５で作成するデータはコマンド処理部で保存してある ページ情報文字列をRefererとすると下記の書式で構成される文字列データである。
【００２７】
【００２８】
この文字列データの長さをＨＴＴＰヘッダ作成部４に与えることでＨＴＴＰ作成部に新しいＨＴＴＰヘッダを生成させる。ページ中継部３は上記フォーマットの文字列データを保持している応答ページデータを先頭に挿入し、クライアントへ送り返す。
以上の動作について、図２を参照して説明する。同図において、クライアントからの要求コマンドを受信すると（ステップＳ２０１）、その受信した要求コマンドを解析する（ステップＳ２０２）。このとき、接続先サーバー情報の取得と保存、取得ＵＲＬ情報の取得と保存、現在のページ情報の取得と保存、を行う。
【００２９】
次に、エラーが発生しているかエラー検査を行う（ステップＳ２０３）。エラーを検出しなければ、サーバーへの接続処理を行う（ステップＳ２０４）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ２０５）。エラーを検出しなければ、サーバーへコマンドを送信する（ステップＳ２０６）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ２０７）。エラーを検出しなければ、サーバーからＨＴＴＰヘッダを受信する（ステップＳ２０８）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ２０９）。エラーを検出しなければ、ＨＴＴＰヘッダを解析する（ステップＳ２１０）。この場合、ＨＴＴＰステータスコードを取得する。その後、ステータスコードを検査する（ステップＳ２１２）。
【００３０】
ステップＳ２０３、Ｓ２０５、Ｓ２０７、Ｓ２０９のいずれかにおいて、エラーを検出した場合は、内部エラーページを作成する（ステップＳ２１１）。この場合、ＨＴＴＰヘッダを作成し、内部エラーページを作成する。その後、ステータスコードを検査する（ステップＳ２１２）。
ステータスコードの検査においては、ステータスコードが４００番台であるか、又は５００番台であるかが確認される。４００番台及び５００番台のステータスコードは、エラーの発生を示すエラーコードだからである。
【００３１】
ステータスコードを検査した結果、エラーを検出すれば、自動ページバックタグ文字列を作成する（ステップＳ２１２→Ｓ２１３）。例えば、
【００３２】
次に、ページバックアンカー文字列を作成する（ステップＳ２１４）。例えば、
＜Ａ ＨＲＥＦ＝“ｈｔｔｐ：／／ｘｘｘｘｘｘｘｘ”＞Ｂａｃｋ＜／Ａ＞
とする。
作成した文字列長を元に、新しいＨＴＴＰヘッダを作成し直す（ステップＳ２１５）。この場合、ＨＴＴＰヘッダには応答ページ長があるので、それを修正する。作成した２つの文字列を応答ページに挿入して、新しい応答ページを作成し直す（ステップＳ２１６）。そして、ステップＳ２１５において作成した新しいＨＴＴＰヘッダをクライアントへ送る（ステップＳ２１７）。さらに、ステップＳ２１６において作成した新しい応答ページをクライアントへ送る（ステップＳ２１８）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ２１９）。以上で処理が終了となる。
【００３３】
一方、ステップＳ２１２において、エラーがなければＨＴＴＰヘッダをクライアントへ送る（ステップＳ２１２→Ｓ２２０）。そして、応答ページをクライアントへ送る（ステップＳ２２１）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ２１９）。以上で処理が終了となる。
以上の処理を行うことにより、エラーが発生すると、以下の表示が行われる。例えば、ファミリーレストランにおいて本システムを導入すると、最初の表示画面には、図３に示されているように、サービスメニューとして「情報サービス」として「交通情報」、「エリアガイド」及び「天気予報」、飲食の「メニュー」として「主食」、「セットメニュー」、「子供メニュー」、「ドリンク」及び「デザート」、「その他のサービス」として「御会計」及び「店員呼び出し」が表示される。ユーザがこの表示画面中の任意のメニューを選択すべく、アンカーが表示されているタッチパネルの表面を押すと、通常はそのリンク先の画面が表示される。
【００３４】
しかしながら、エラーが発生すると、図４に示されているように、「エラー発生を検出しました。暫くすると、直前のページに戻ります。もう一度トライしてもダメな場合は、御手数ですが、店員へ連絡してください。」及び「ＨＴＴＰ／１．０ ４０４オブジェクトが見つかりません」というメッセージと共に、「手動強制ページバック」という文字列のアンカーが画面に表示される。
【００３５】
上述した従来のシステムにおいては、図８に示されているようにエラーの発生の旨を伝えるだけの画面が表示されるにすぎないので、主電源を再投入して復旧させるしか手段がなかった。これに対し、本システムでは「手動強制ページバック」という文字列のアンカーが表示されているタッチパネルの表面を押すことによって、強制的に直前のページに戻ることができる。
【００３６】
以上説明した第１の実施形態においては、以下のようなプロキシサーバーの制御方法が実現されていることになる。すなわち、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であり、上記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、このエラーページ検出ステップにおいてエラーページを検出したときそのエラーを回避することのできるページを生成するページ生成ステップと、このページ生成ステップにおいて生成したページを上記クライアントに送出するページ送出ステップとを含む制御方法が実現されていることになる。そして、上記ページ生成ステップにおいては、上記エラーページ検出ステップにおいてエラーページを検出したとき直前のページに戻るためのタグを生成し、上記ページ送出ステップにおいては、生成した上記タグを有するページを上記クライアントに送出している。
【００３７】
さらに、図２等に示されている動作を実現するためのプログラムを用意し、これを用いてコンピュータを制御すれば、上述と同様の処理を行うことができることは明白である。このプログラムを記録するための記録媒体には、図１等に示されていない半導体メモリ、磁気ディスク、光ディスク等の他、種々の記録媒体を用いることができる。
【００３８】
なお、上記はファミリーレストランにおいてユーザが操作する端末を含むシステムを例として説明したが、その場合に限らず種々端末を用いるシステムについて本発明が適用できることは明らかである。
図５は本発明によるプロキシサーバーの第２の実施形態を示すブロック図である。同図に示されているように、本実施形態によるプロキシサーバーは、クライアント（図示せず）からのコマンドの解析等を行うコマンド処理部１と、ＨＴＴＰヘッダの解析等を行うデータ受信部２と、エラーページを送出するエラーページ送出部６と、ＨＴＴＰヘッダ作成部ＨＴＴＰヘッダ作成部４と、差し換えページを作成する差し換えページ生成部７とを含んで構成されている。
【００３９】
かかる構成において、コマンド処理部１はクライアントからのコマンドの解析と処理を行う。この処理でエラーを検出した場合には、応答ページ処理へエラー内容の通知を行う。エラーが無ければｗｗｗサーバー（図示せず）ヘコマンドを送る。
データ受信部２はｗｗｗサーバーから送られてくるＨＴＴＰヘッダの解析を行う。この解析において、ステータスコードにエラーコードを検出した場合には、エラーページ送出部６へエラーコードを渡す。
【００４０】
エラーページ送出部６は受け取ったエラーコードを、ＨＴＴＰヘッダ作成部４に渡す。ＨＴＴＰヘッダ作成部４では、新しいＨＴＴＰヘッダを作成して、エラーページ送出部６に渡す。また、エラーページ送出部６は受け取ったエラーコードを、差し換えページ生成部７へ渡す。差し換えページ生成部７は差し換えるべき応答ページを探し出し、エラーページ送出部６へ渡す。
【００４１】
エラーページ送出部６は、新しいＨＴＴＰヘッダと、差し換え応答ページとをクライアントへ送り返す。
データ受信部２は、ｗｗｗサーバーから送られてくるＨＴＴＰヘッダに含まれている応答ステータスコードを取り出し、エラー状態を示す、４００番台、５００番台のエラーコードかどうかの検査を絶えず行っている。検査の結果、応答ステータスコードが４００番台、５００番台を検出した場合には、ｗｗｗサーバーで何かしらのエラーが起きていることが判るので、プロキシサーバーは応答ページを差し換えすべき状態を検出できる。
【００４２】
ここで、差し換えるページの特定方法には、種々の方法が考えられる。すなわち、例えば差し換えページの格納ディレクトリを指定しておき、
「error」＋「３桁の数字」＋「.htm」
からなるファイル名の生成規則を仮定する。そして、３桁の数字が一致するファイルがある場合にはそのファイルを差し換えファイルとしてクライアントへ返す。一方、もしそのファイルが見つからなければ、デフォルトの処理を定義した差し換えページを指定する。
【００４３】
以上の動作について、図６を参照して説明する。同図において、クライアントからの要求コマンドを受信すると（ステップＳ６０１）、その受信した要求コマンドを解析する（ステップＳ６０２）。このとき、接続先サーバー情報の取得と保存、取得ＵＲＬ情報の取得と保存、現在のページ情報の取得と保存、を行う。次に、エラーが発生しているかエラー検査を行う（ステップＳ６０３）。エラーを検出しなければ、サーバーへの接続処理を行う（ステップＳ６０４）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ６０５）。エラーを検出しなければ、サーバーへコマンドを送信する（ステップＳ６０６）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ６０７）。エラーを検出しなければ、サーバーからＨＴＴＰヘッダを受信する（ステップＳ６０８）。ここでもエラーが発生しているかエラー検査を行う（ステップＳ６０９）。エラーを検出しなければ、ＨＴＴＰヘッダを解析する（ステップＳ６１０）。この場合、ＨＴＴＰステータスコードを取得する。その後、ステータスコードを検査する（ステップＳ６１２）。
【００４４】
ステップＳ６０３、Ｓ６０５、Ｓ６０７、Ｓ６０９のいずれかにおいて、エラーを検出した場合は、内部エラーページを作成する（ステップＳ６１１）。この場合、ＨＴＴＰヘッダを作成し、内部エラーページを作成する。その後、ステータスコードを検査する（ステップＳ６１２）。
ステータスコードの検査においては、ステータスコードが４００番台であるか、又は５００番台であるかが確認される。ステータスコードを検査した結果、エラーを検出すれば、差し換えページの検索が行われる（ステップＳ６１２→Ｓ６１３）。この場合、ステータスコードに応じた差し換えページがあるか判断される。差し換えページが検出できれば、新しいＨＴＴＰヘッダを作成する（ステップＳ６１３→Ｓ６１４）。この場合、差し換えページ長を元に、新しいＨＴＴＰヘッダを作成し直す。
【００４５】
次に、作成した新しいＨＴＴＰヘッダをクライアントへ送る（ステップＳ６１５）。そして、差し換えする応答ページをクライアントへ送る（ステップＳ６１６）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ６１７）。以上で処理が終了となる。
一方、ステップＳ６１２において、エラーがなければＨＴＴＰヘッダをクライアントへ送る（ステップＳ６１８）。そして、応答ページをクライアントへ送る（ステップＳ６１９）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ６１７）。以上で処理が終了となる。
【００４６】
また、ステップＳ６１３において、差し換えページを検索したが、差し換えページのファイルが見つからない場合、ＨＴＴＰヘッダをクライアントへ送る（ステップＳ６１８）。そして、応答ページをクライアントへ送る（ステップＳ６１９）。この後、サーバー側、クライアント側のコネクションを切断する（ステップＳ６１７）。以上で処理が終了となる。
【００４７】
以上の処理を行うことにより、エラーが発生すると、以下の表示が行われる。例えば、ファミリーレストランにおいて本システムを導入すると、最初の表示画面には、図３に示されているように、サービスメニューとして「情報サービス」として「交通情報」、「エリアガイド」及び「天気予報」、飲食の「メニュー」として「主食」、「セットメニュー」、「子供メニュー」、「ドリンク」及び「デザート」、「その他のサービス」として「御会計」及び「店員呼び出し」が表示される。ユーザがこの表示画面中の任意のメニューを選択すべく、アンカーが表示されているタッチパネルの表面を押すと、通常はそのリンク先の画面が表示される。
【００４８】
しかしながら、エラーが発生すると、図７に示されているように、「ちょっとお待ちください」及び「サーバーの調子が良くありません。御手数ですが、下記のいずれかの処理を御選びください。」というメッセージの他に、「トップページへ戻る」、「もう一度リトライしてみる」及び「サーバー不調を店員へ連絡」という各文字列のアンカーが画面に表示される。このような表示画面を見たユーザは、「トップページへ戻る」、「もう一度リトライしてみる」、「サーバー不調を店員へ連絡」、のいずれかのアンカーを選択し、そのアンカーが表示されているタッチパネルの表面を押すことになる。こうすれば、サービスを中断させることはない。
【００４９】
上述した従来のシステムにおいては、図８に示されているようにエラーの発生の旨を伝えるだけの画面が表示されるにすぎない。つまり、サービスが中断し、エラーそのものをユーザに見せてしまうことになる。また、この画面から復旧させるには主電源を再投入するしか手段がない。
これに対し、本システムでは差し換えるページをエラー内容に応じて予め指定しておき、図８に示されているようなエラーページがｗｗｗサーバーから送られてきたことを検出したとき、図７に示されているようなページを画面に表示することにより、ユーザに違和感を与えずにサービスを安定して提供することができる。
【００５０】
以上説明した第２の実施形態においては、以下のようなプロキシサーバーの制御方法が実現されていることになる。すなわち、ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であり、エラー発生の旨を表示するエラーページの代わりに上記クライアントに送出すべき差し換えページを生成するページ生成ステップと、上記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、このエラーページ検出ステップがエラーページを検出したとき該エラーページの代わりに上記ページ生成ステップにおいて生成した差し換えページを上記クライアントに送出するページ送出ステップとを含む制御方法が実現されている。
【００５１】
さらに、図６等に示されている動作を実現するためのプログラムを用意し、これを用いてコンピュータを制御すれば、上述と同様の処理を行うことができることは明白である。このプログラムを記録するための記録媒体には、図５等に示されていない半導体メモリ、磁気ディスク、光ディスク等の他、種々の記録媒体を用いることができる。
【００５２】
なお、上記はファミリーレストランにおいてユーザが操作する端末を含むシステムを例として説明したが、その場合に限らず種々端末を用いるシステムについて本発明が適用できることは明らかである。
【００５３】
【発明の効果】
以上説明したように本発明は、自動的に直前のページに戻るタグを挿入することにより、前のページに戻る機能を持っていないＷＥＢ端末を用いても、エラー応答ページがプロキシサーバーを経由してクライアントへ送り返される時に、直前のページに戻ることができるので、ページ閲覧の中断が回避され、サービスの中断を回避できるという効果がある。
【図面の簡単な説明】
【図１】本発明によるプロキシサーバーの実施の第１の形態を示すブロック図である。
【図２】図１のプロキシサーバーの動作を示すフローチャートである。
【図３】表示画面の例を示す図である。
【図４】エラー発生時における表示画面の例を示す図である。
【図５】本発明によるプロキシサーバーの実施の第２の形態を示すブロック図である。
【図６】図５のプロキシサーバーの動作を示すフローチャートである。
【図７】エラー発生時における表示画面の例を示す図である。
【図８】エラー発生時における表示画面の従来例を示す図である。
【符号の説明】
１ コマンド処理部
２ データ受信部
３ ページ中継部
４ ＨＴＴＰヘッダ作成部
５ 自動タグ生成部
６ エラーページ送出部
７ 差し換えページ生成部
Claims (6)
- ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーであって、
前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出手段と、
前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出手段がエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成手段と、
このページ生成手段によって生成したページを前記クライアントに送出するページ送出手段と、を含むことを特徴とするプロキシサーバー。 - 前記エラーページ検出手段は、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする請求項１記載のプロキシサーバー。
- ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御する制御方法であって、
前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、
前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出ステップにおいてエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成ステップと、
このページ生成ステップにおいて生成したページを前記クライアントに送出するページ送出ステップと、を含むことを特徴とする制御方法。 - 前記エラーページ検出ステップにおいては、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする請求項３記載の制御方法。
- ｗｗｗサーバーから送られてくるページを中継してクライアントに送出するプロキシサーバーを制御するプログラムであって、
前記ｗｗｗサーバーから送られてきたページがエラー発生の旨を表示するエラーページであることを検出するエラーページ検出ステップと、
前記クライアントで現在表示中のページを特定するページ情報を獲得し、前記エラーページ検出ステップにおいてエラーページを検出したとき、前記ページ情報をもとに前記表示中のページを表示するためのタグを生成し、このタグを送られてきたページに挿入して、前記表示中のページを再度表示させるための新たなページを生成するページ生成ステップと、
このページ生成ステップにおいて生成したページを前記クライアントに送出するページ送出ステップと、を含むことを特徴とするプログラム。 - 前記エラーページ検出ステップにおいては、ステータスコードがエラーを示す値であるかによってエラーページであることを検出することを特徴とする請求項５記載のプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001030407A JP4165018B2 (ja) | 2001-02-07 | 2001-02-07 | プロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001030407A JP4165018B2 (ja) | 2001-02-07 | 2001-02-07 | プロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002229887A JP2002229887A (ja) | 2002-08-16 |
| JP2002229887A5 JP2002229887A5 (ja) | 2005-04-07 |
| JP4165018B2 true JP4165018B2 (ja) | 2008-10-15 |
Family
ID=18894628
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001030407A Expired - Fee Related JP4165018B2 (ja) | 2001-02-07 | 2001-02-07 | プロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4165018B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3709797B2 (ja) * | 2001-02-27 | 2005-10-26 | 日本電気株式会社 | プロキシサーバとウェブサーバを含むシステム及びそのプログラム |
| US7284160B2 (en) | 2002-12-13 | 2007-10-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Error messaging method in HTTP based communication systems |
| JP2006260343A (ja) * | 2005-03-18 | 2006-09-28 | Nifty Corp | リンク切れチェックプログラム |
| JP2007304837A (ja) * | 2006-05-11 | 2007-11-22 | Nec Fielding Ltd | 情報処理装置及び監視方法並びにプログラム |
| JP4913002B2 (ja) * | 2007-09-28 | 2012-04-11 | 株式会社日立ソリューションズ | Ｗｅｂアプリケーション監視装置 |
| JP5272595B2 (ja) * | 2008-09-05 | 2013-08-28 | 沖電気工業株式会社 | 表示制御装置、表示制御システム、表示制御方法およびプログラム |
-
2001
- 2001-02-07 JP JP2001030407A patent/JP4165018B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002229887A (ja) | 2002-08-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6785740B1 (en) | Text-messaging server with automatic conversion of keywords into hyperlinks to external files on a network | |
| US7162526B2 (en) | Apparatus and methods for filtering content based on accessibility to a user | |
| US7253919B2 (en) | Printer with embedded retrieval and publishing interface | |
| US6405222B1 (en) | Requesting concurrent entries via bookmark set | |
| US8103737B2 (en) | System and method for previewing hyperlinks with ‘flashback’ images | |
| US7015922B2 (en) | Image display method and portable terminal for displaying selected image | |
| US6823365B1 (en) | Method and apparatus for redirection of data when electronic mail is restricted | |
| US20040205496A1 (en) | Displaying subheadings and hyperlinks in a scrollable long document | |
| US20040095400A1 (en) | Reconfiguration of content for display on devices of different types | |
| US20020049777A1 (en) | File conversion method, file converter, and file display system | |
| US20100145924A1 (en) | Methods and Devices for Locating Information on a Web Page | |
| CN103500194A (zh) | 一种进行网页加载的方法、装置和浏览器 | |
| US20110282978A1 (en) | Browser plug-in | |
| US7739609B2 (en) | Method and system for responding to inquiries from users | |
| JP4165018B2 (ja) | プロキシサーバー、プロキシサーバー制御方法、及びプロキシサーバーを制御するためのプログラム | |
| WO2011093892A1 (en) | Remote printing | |
| US20110314385A1 (en) | Method and apparatus for producing graphical machine vision content for distribution via a network | |
| US8522131B1 (en) | Intermediation system and method for enhanced rendering of data pages | |
| US6636235B1 (en) | Lettering adjustments for display resolution | |
| US20020143817A1 (en) | Presentation of salient features in a page to a visually impaired user | |
| JP2009211278A (ja) | 携帯端末を利用した検索システムおよびその検索方法 | |
| JPH10289250A (ja) | Ｗｗｗブラウザにおけるｕｒｌ登録及び表示方式 | |
| JP2002149478A (ja) | 更新情報の自動表示方法、装置、媒体およびプログラム | |
| JPH1065853A (ja) | ファクシミリ装置 | |
| JP2001022788A (ja) | 情報検索装置および情報検索プログラムを記録した記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040430 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040430 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061106 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070116 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070319 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080401 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080430 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080604 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080708 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080721 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110808 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130808 Year of fee payment: 5 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |