JP4179535B2 - ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム - Google Patents
ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム Download PDFInfo
- Publication number
- JP4179535B2 JP4179535B2 JP2002257969A JP2002257969A JP4179535B2 JP 4179535 B2 JP4179535 B2 JP 4179535B2 JP 2002257969 A JP2002257969 A JP 2002257969A JP 2002257969 A JP2002257969 A JP 2002257969A JP 4179535 B2 JP4179535 B2 JP 4179535B2
- Authority
- JP
- Japan
- Prior art keywords
- web server
- cookie
- domain
- header
- request
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上でサーバと外部ネットワークとの間に介在させるリバースプロキシに関し、特にサーバがクッキーを設定する場合のリバースプロキシの処理等に関する。
【０００２】
【従来の技術】
ネットワークにおいて種々のサービスを提供するサーバのセキュリティを強化するため、ネットワーク上にリバースプロキシを設置することが行われる。リバースプロキシとは、サーバに代わって当該サーバへの要求を受信し中継するプロキシサーバである。すなわち、当該サーバにアクセスしようとしたユーザは全てリバースプロキシを経由することになるため、当該サーバが外部から直接アクセスを受けることがなくなる。
【０００３】
リバースプロキシを経由してサーバへアクセスする場合、アクセス要求（リクエスト）には一般に次のフォーマットが用いられる。なお、以下の例では通信プロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）を用い、ウェブサーバへアクセスする場合について説明する。
（１）http://<reverse proxy>/<prefix>/<path name of Web server>
（２）http://<web server>/<path name of Web server>
リバースプロキシは、<prefix>とウェブサーバ名とを対応付けた図１２に示すようなテーブルを管理している。そして、（１）のフォーマットのリクエストを受け取ると、図１２のテーブルを参照し、リクエスト中の<prefix>に対応するウェブサーバに対して（２）のフォーマットのリクエストを送る。
【０００４】
ところで、ＨＴＴＰリクエストは、ステートレスつまり各リクエストが独立であるため、ウェブサーバは、１人のユーザからの連続するリクエストであっても１つ１つ独立したリクエストと認識する。そこで、リクエスト間で状態を保持するためにクッキー（Cookie）が導入されている。
クッキーはウェブサーバがブラウザに設定するものであり、例えば以下のようにしてユーザを追跡することができる。
まず、ウェブサーバがユーザからのリクエストに対してレスポンスを返す際に、レスポンス内に、
Set-Cookie: id=001
のようなSet-Cookie（セットクッキー）をヘッダに埋め込む。これにより、その後の当該ユーザからの全てのリクエストには、リクエストヘッダ内に、
Cookie: id=001
というクッキーが埋め込まれる。この情報に基づいて、当該ユーザがどのページにアクセスしたかを追跡することができる。
【０００５】
ここで、上記のSet-Cookieを埋め込んだヘッダ（以下、Set-Cookie ヘッダ）は、以下のようなフォーマットを持つ。
Set-Cookie: <name>=<value>; domain=<domain>; path=<path>;（その他）
ドメイン（domain）、パス（path）の指定により、これを受け取ったブラウザがクッキーを送り返す範囲を制限している。つまり、ドメインで指定された範囲内のウェブサーバにおいて、パスで指定されているディレクトリ（directory）以下のアクセスに対してのみクッキーが送り返されることとなる。
【０００６】
【発明が解決しようとする課題】
しかし、リバースプロキシが設置されたネットワークシステムにおいて、リバースプロキシからサーバへ送られたリクエスト（例えば上述した（２）のフォーマットのリクエスト）に対する当該サーバからのレスポンス内にSet-Cookieヘッダがあった場合、このレスポンスをそのままリバースプロキシがリクエストを行ったブラウザ（ユーザ端末）へ返すと、一般的に当該ブラウザはこのSet-Cookieを正しく受け取ることができない。
その理由は、Set-Cookieはドメイン、パスを特定するパラメータによってその有効範囲を指定しているが、サーバ本来のドメイン及びパスと、リバースプロキシを通したときの当該サーバのドメイン及びパスが異なるためである。例えば、ウェブサーバが、自身が属するドメインの値をドメインパラメータに設定してSet-Cookieを設定した場合において、ブラウザから認識できるリバースプロキシがSet-Cookieで指定されているドメインに存在しない場合は、ブラウザはこのSet-Cookieを無視してしまうためである。
【０００７】
そこで本発明は、リバースプロキシを経由してサーバへアクセスするネットワークシステムにおいて、サーバによって設定されたクッキーを透過的に扱うようにすることを目的とする。
また本発明は、サーバの設定したクッキーを有効に使用するためにSet-Cookieを書き換える機能を備えたリバースプロキシを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成する本発明は、次のようなネットワークシステムによって実現される。すなわち、このネットワークシステムは、ネットワーク上に設けられた複数のウェブサーバと、この複数のウェブサーバに対する外部からのアクセスを中継するリバースプロキシとを備え、このネットワークシステムにおいてウェブサーバは、ネットワークに接続された所定の端末から送信されたリクエストに応じて端末の状態を保持するための情報を含むレスポンスをこの端末に返送し、リバースプロキシは、このレスポンスに含まれる端末の状態を保持するための情報を、この端末がネットワークの構成として認識可能な形式に変換して返送する。そして、リバースプロキシは、端末の状態を保持するための情報に含まれるウェブサーバのドメインを指定するドメインパラメータを削除し、ドメインパラメータを構成する構成要素の並び順を逆順に並べ替えて、この情報に含まれるウェブサーバにおけるパスパラメータに埋め込む。
【０００９】
また、本発明は、次のような機能構成を有するリバースプロキシによって実現される。ウェブサーバからユーザ端末へのデータの送信を中継するリバースプロキシは、ウェブサーバからユーザ端末に返送されたデータを受信すると共に、このデータに含まれるSet-Cookieヘッダのドメイン、パスの記述をユーザ端末が認識可能な形式に書き換えるヘッダ書き換え部と、このヘッダ書き換え部によって書き換えられたデータをユーザ端末に送信するデータ送信部とを備える。また、このリバースプロキシは、このデータに含まれるリンク及びロケーションのドメイン及びパスをヘッダ書き換え部によって書き換えられたドメインの記述を含むパスに合わせて書き換えるリンク・ロケーション書き換え部をさらに備える。
【００１０】
さらに、本発明は、次のような機能構成を有するリバースプロキシによって実現される。ユーザ端末からウェブサーバへのリクエストの送信を中継するリバースプロキシは、受信されたリクエストの記述を変換して得られる情報（ドメインに関する情報）に基づいてネットワーク上に配置された複数のサーバのうちこのリクエストを送信するウェブサーバを特定するウェブサーバ名取得部と、このウェブサーバ名取得部にて特定されたウェブサーバに基づいて、このリクエストによるアクセス先をこのウェブサーバにおけるＵＲＬに書き換えるＵＲＬ書き換え部と、ウェブサーバのＵＲＬにこのリクエストを転送するリクエスト転送部とを備える。
【００１１】
またさらに、本発明は、次のようなコンピュータ装置を提供することができる。すなわち、端末とサーバとの間におけるＨＴＴＰリクエストの送信及びＨＴＴＰレスポンスの返送を中継するコンピュータ装置は、この端末のブラウザから送信されたクッキーとＨＴＴＰリクエストとを中継してこのＨＴＴＰリクエストの送信先のサーバに転送するＨＴＴＰリクエスト転送手段と、このＨＴＴＰリクエストに応じてこのサーバから返送されたＨＴＴＰレスポンスを受信し、セットクッキーヘッダに記述されたドメインを削除してこのドメインを構成する構成要素の並び順を逆順に並べ替えて、セットクッキーヘッダに記述されたパスに埋め込んでこの端末に転送するＨＴＴＰレスポンス転送手段とを備える。ここで、このＨＴＴＰリクエスト転送手段は、ウェブサーバがデフォルトのポート以外を使用している場合は、ブラウザのリバースプロキシに対するアクセスパス内にウェブサーバのポート番号を指定してアクセスする。また、この前記ＨＴＴＰレスポンス転送手段は、ＨＴＴＰレスポンスに応じて所定の固定文字列をセットクッキーヘッダに付け加えて端末に転送する。さらに、ＨＴＴＰレスポンス転送手段は、ドメインの構成要素の並び順を逆順に並べ替える際に、このドメインを特定するのに必要な構成要素を１つに纏めて端末に転送する。またさらに、ＨＴＴＰレスポンス転送手段は、サーバのセットクッキーヘッダ内のドメインパラメータを自装置のサーバ名に置換して端末に転送する。
【００１２】
さらにまた、本発明は、次のようなデータ処理方法を提供することができる。すなわち、第１のコンピュータ装置と第２のコンピュータ装置とのデータの送受信を中継するコンピュータ装置におけるデータ処理方法は、第１のコンピュータ装置から第２のコンピュータ装置に対して送信されたレスポンスを受信するステップと、このレスポンスにセットクッキーヘッダが含まれているか否かを判断するステップと、このレスポンスにセットクッキーヘッダが含まれている場合には、セットクッキーヘッダに基づいて第２のコンピュータ装置に設定されるクッキーがこの第２のコンピュータ装置において認識可能な形式となるようにセットクッキーヘッダを書き換えるステップと、このセットクッキーヘッダが書き換えられたレスポンスを第２のコンピュータ装置に送信するステップとを含む。
また、第１のコンピュータ装置と第２のコンピュータ装置とのデータの送受信を中継するコンピュータ装置におけるデータ処理方法は、第２のコンピュータ装置から送信されたリクエストを受信し、
このリクエストの情報を変換して得られる情報に基づいてこのリクエストを送信する第１のコンピュータ装置を特定するステップと、このリクエストによるアクセス先を特定された第１のコンピュータ装置におけるＵＲＬに書き換えるステップと、特定されたこの第１のコンピュータ装置のＵＲＬにリクエストを送信するステップとを含む。
【００１３】
ここで本発明は、上述した所定のデータ処理を行う方法の各ステップによる処理、及び各部の機能において実現される処理をコンピュータを制御して実行するプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
【００１４】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
図１は、本実施の形態におけるネットワークシステムの構成を示す図である。図１に示すように、本実施の形態におけるネットワークシステムは、外部からのリクエストに応じたコンテンツを提供すると共にクッキーを返送するウェブサーバ２００と、このウェブサーバ２００へのリクエストの送信及びこのリクエストに対するウェブサーバ２００からのレスポンスを例えばＬＡＮ網からなるネットワーク４００を介して中継するリバースプロキシ１００と、このリバースプロキシ１００に例えばインターネット網からなるネットワーク５００を介して接続され、ウェブサーバ２００へのリクエストを送信すると共にウェブサーバ２００からのレスポンスを受信するユーザ端末３００とを備える。
図示するように、本実施の形態におけるネットワークにおいてウェブサーバ２００は、異なるドメインを有する複数のウェブサーバ２０１，２０２などから構成される。また図示するように、このウェブサーバ２００には、ブラウザ３０１ａ，３０２ａを備えたユーザ端末３０１，３０２などの複数の端末から任意にアクセスすることができる。以下では、このウェブサーバ２００にアクセスする端末が物理的に同じ端末であっても、ログインするユーザに応じて異なる端末であるものとみなす。
【００１５】
以下、本実施の形態では、ウェブサーバ２００とユーザ端末３００との通信プロトコルとしてＨＴＴＰを用い、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受信を行う場合について説明する。
図１に示したウェブサーバ２００は、例えばサーバとして外部からのアクセス負荷に耐え得る機能を備えたコンピュータ装置などからなる。このウェブサーバ２００は、ユーザ端末３００から送信されたＨＴＴＰリクエストに対してデータやファイル（ＨＴＴＰレスポンス）を返送することにより、このユーザ端末３００にＨＴＴＰリクエストに応じたコンテンツを提供する。そしてこのウェブサーバ２００は、ユーザ端末３００にＨＴＴＰレスポンスを返送する際、このＨＴＴＰレスポンス内にSet-Cookieヘッダを埋め込んで返送する。ウェブサーバ２００から返送されるＨＴＴＰレスポンスは、一旦、ウェブサーバ２００とユーザ端末３００との間に設けられたリバースプロキシ１００によって受信される。本実施の形態では、このウェブサーバ２００において埋め込まれたSet-Cookieヘッダを含むＨＴＴＰレスポンスは、リバースプロキシ１００において所定の形式に変換される。
【００１６】
リバースプロキシ１００は、例えばウェブサーバ２００とユーザ端末３００とをＨＴＴＰリクエスト及びＨＴＴＰレスポンスを中継するネットワーク機能を備えたコンピュータ装置などからなる。このリバースプロキシ１００は、ユーザ端末３００からのＨＴＴＰリクエストを中継して、このＨＴＴＰリクエストにて特定されるウェブサーバ２００にＨＴＴＰリクエストを転送する。さらにこのリバースプロキシ１００は、転送したＨＴＴＰリクエストに応じてウェブサーバ３００から返信されてきたＨＴＴＰレスポンスを中継する。
ここで、本実施の形態におけるリバースプロキシ１００は、ウェブサーバ２００から返送されたSet-Cookieヘッダを含むＨＴＴＰレスポンスを受信して、このＨＴＴＰレスポンス内のSet-Cookieヘッダを所定の形式に変換する。さらにこのＨＴＴＰレスポンスに含まれるリンク・ロケーションヘッダの書き換えを行う。そして、Set-Cookieヘッダ、及びリンク・ロケーションヘッダが書き換えられたＨＴＴＰレスポンスを、ＨＴＴＰリクエストを行ったユーザ端末３００に対して送信する。リバースプロキシ１００において実現されるこれらの機能の詳細については後述する。
【００１７】
またユーザ端末３００は、例えばパーソナルコンピュータやワークステーションなどからなる。これらのユーザ端末３００は、キーボードやマウス等の操作部及びディスプレイ等の表示部を有する。また、このユーザ端末３００は、プログラム制御に応じて動作するブラウザ３００ａを備える。このブラウザ３００ａは、操作部における操作に応じて表示部にブラウザウィンドウ（画面）を表示すると共に、種々のウェブサーバ２００によって設定されたクッキーを管理する。そしてブラウザ３００ａは、このブラウザウィンドウに対して所定の操作が行われることにより、ネットワーク接続されたウェブサーバ２００に対して例えばＨＴＴＰリクエストを送信する。ユーザ端末３００は、このＨＴＴＰリクエストに応じてウェブサーバ２００から返送されたＨＴＴＰレスポンスに基づいて、ブラウザ３００ａ上にコンテンツを表示する。
さらにこのブラウザ３００ａには、ＨＴＴＰレスポンスに埋め込まれてウェブサーバ２００から返送されたSet-Cookieヘッダに基づいてクッキーが設定される。ブラウザ３００ａはこのクッキーを保持し、次回以降にこのクッキーの有効範囲となるウェブサーバ２００にＨＴＴＰリクエストを送信する際には、このＨＴＴＰリクエストにクッキーを埋め込んで送信する。そうすると、このクッキーを含むＨＴＴＰリクエストを受信したウェブサーバ２００は、同じユーザ端末３００から送信されるＨＴＴＰリクエストの関連性を保つと共に、ユーザ端末３００の状態を保持することができるようになる。
【００１８】
以下では、リバースプロキシ１００の機能について述べるが、ここで、ユーザ端末３００から送信されたＨＴＴＰリクエストに基づいてウェブサーバ２００から返送されるＨＴＴＰレスポンスに含まれるSet-Cookieヘッダについて説明する。
ＨＴＴＰレスポンスに含まれるSet-Cookieヘッダには、ドメイン、パスパラメータが記述されている。そして、この情報によって、ユーザ端末３００のブラウザ３００ａには、クッキーの有効範囲が設定される。以下、図１１を用いてウェブサーバ２００からユーザ端末３００に返送されるＨＴＴＰレスポンスに含まれるSet-Cookieヘッダ、及びユーザ端末３００からウェブサーバ２００に送信されるＨＴＴＰリクエストのリクエストヘッダに埋め込まれるクッキーについて説明する。
【００１９】
図１１は、ウェブサーバ２００から送信されるSet-Cookieヘッダによって決められるクッキーの有効範囲と、このクッキーの有効範囲であるウェブサーバ２００に送信されるＨＴＴＰリクエスト及びクッキーの一例を示す図である。
図示した例では、ネットワーク上に、ウェブサーバ２０１（ドメイン：“www.sub.abc.com”）、ウェブサーバ２０２（ドメイン：“www2.sub.abc.com”）、ウェブサーバ２０３（ドメイン：“www3.abc.com”）、ウェブサーバ２０４（ドメイン：“www.xyz.com”）の複数のウェブサーバ２００が配置されている。そして、このウェブサーバ２００との間でＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受信を行うユーザ端末３００がネットワークを介して接続されている。ウェブサーバ２０１は、ユーザ端末３００から送信されたＨＴＴＰリクエストに応じて、
(１)Set-Cookie:name1=value1；domain=www.sub.abc.com；path=/；
Set-Cookie:name2=value2；domain=www.sub.abc.com；path=/path1/；
Set-Cookie:name3=value3；domain=sub.abc.com；path=/；
Set-Cookie:name4=value4；domain=abc.com；path=/；
というSet-Cookieヘッダ（１）を含むＨＴＴＰレスポンスを返送する。
そうすると、ユーザ端末３００のブラウザ３００ａには、このSet-Cookieヘッダ（１）に基づいてクッキーが設定され、保持される。このSeｔ−Cookieヘッダ（１）に基づいて設定されるクッキーの有効範囲は、
name1：www.sub.abc.com；
name2：www.sub.abc.com/path1；
name3：www.sub.abc.com；www2.sub.abc.com；
name4：www.sub.abc.com；www2.sub.abc.com；www3.sub.abc.com；
である。
【００２０】
図１１に示した例では、ユーザ端末３００からウェブサーバ２０１にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（２）GET /index.html
Cookie：name1=value1；name3=value3；name4=value4；
が埋め込まれて送信される。
ユーザ端末３００からウェブサーバ２０１のディレクトリ（“/path1/”）にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（３）GET /path1/index.html
Cookie：name1=value1；name2=value2；name3=value3；name4=value4；
が埋め込まれて送信される。
ユーザ端末３００からウェブサーバ２０２にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（４）GET /index.html
Cookie：name3=value3；name4=value4；
が埋め込まれて送信される。
ユーザ端末３００からウェブサーバ２０３にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（５）GET /index.html
Cookie：name4=value4；
が埋め込まれて送信される。
また、ユーザ端末３００からウェブサーバ２０４にＨＴＴＰリクエストを送信する場合についてだが、このウェブサーバ２０４を有効範囲とするクッキーは存在しないので、このＨＴＴＰリクエストのリクエストヘッダにクッキーは埋め込まれない。すなわち
（６）GET /index.html
だけが送信される。
以上のように、ユーザ端末３００からウェブサーバ２００にＨＴＴＰリクエストを送信する際、このＨＴＴＰリクエストのリクエストヘッダには、それぞれのクッキーの有効範囲に基づいて、ＨＴＴＰリクエストの送信先となるウェブサーバ２００に応じたクッキーが埋め込まれて送信されていた。
【００２１】
上記のように、ＨＴＴＰレスポンスと共にSet-Cookieヘッダを受信したユーザ端末３００のブラウザ３００ａは、Set-Cookieヘッダにて示された有効範囲に対するクッキーを設定する。しかしながらユーザ端末３００のブラウザ３００ａから見ると、リバースプロキシ１００を介してＨＴＴＰレスポンスを受信する場合には、このＨＴＴＰリクエストの送信元はウェブサーバ２００ではなくリバースプロキシ１００である。一般的に、ウェブサーバ２００が返すSet-Cookieヘッダ内のドメインパラメータ、パスパラメータの値は、リバースプロキシ１００上でのドメインパラメータ、パスパラメータの値としては正しくないため、このSet-Cookieヘッダを受け取ったブラウザ３００ａは、このSet-Cookieヘッダを無視するか、または正しくない範囲に対してクッキーを送り返すことになる。
【００２２】
そこで本実施の形態では、リバースプロキシ１００を介してウェブサーバ２００からユーザ端末３００のブラウザ３００ａへレスポンスを返送する場合であっても、ブラウザ３００ａにSet-Cookieヘッダを透過的に扱うための変形を行う。 Set-Cookieヘッダの変形方法として本実施の形態では、このSet-Cookieヘッダに含まれるドメインパラメータ（ドメインに関する情報）を削除して、このドメインに関する情報をパスパラメータ（パスに関する情報）に埋め込む。この際、このSet-Cookieヘッダによって設定されるクッキーの有効範囲を階層的に絞り込むために、ドメインに関する情報を構成する構成要素を逆順に並べ替える。例えば、“www.abc.com”の構成要素の並び順を“com.abc.www”とする。さらにこの構成要素を区切る区切り文字“.”を“/”として置換したものをパスに関する情報に埋め込む。
以下、本実施の形態では、ＦＱＤＮ（Full Qualified Domain Name）が上述のようにして加工されたものを「リバースドＦＱＤＮ」（Reversed Full Qualified Domain Name）と称する。
【００２３】
以上のように本実施の形態では、Set-Cookieヘッダに含まれるドメイン情報を削除し、このドメイン情報に対してリバースドＦＱＤＮと同様の操作をしたものをパスに関する情報に埋め込んでSet-Cookieヘッダを書き換える。このようにしてSet-Cookieヘッダを書き換えれば、ブラウザ３００ａにおいて受信されるSet-Cookieヘッダ内にドメインパラメータが存在しないので、リバースプロキシ１００から送信されたSet-Cookieヘッダであっても無視されることはない。そして、次回以降にクッキーの有効範囲に対してＨＴＴＰリクエストを送信する際には、このＨＴＴＰリクエストに当該クッキーを埋め込んで送信する。
【００２４】
図２は、本実施の形態におけるリバースプロキシ１００の機能を示すブロック図である。以下、図２に例示する各機能は、リバースプロキシ１００のプログラム制御されたＣＰＵにて実現されるソフトウェアブロックである。
図２に示すように、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスを中継するリバースプロキシ１００は、ＨＴＴＰリクエストを送信するウェブサーバ２００を特定するウェブサーバ名取得部１１０と、ＨＴＴＰリクエストの送信先のＵＲＬを書き換えるＵＲＬ書き換え部１２０と、ＨＴＴＰリクエストをこのウェブサーバ２００に転送するＨＴＴＰリクエスト転送部１３０とを備える。上記のウェブサーバ名取得部１１０と、ＵＲＬ書き換え部１２０と、ＨＴＴＰリクエスト転送部１３０とで、ＨＴＴＰリクエストをウェブサーバ２００に転送するＨＴＴＰリクエスト転送手段を構成する。
本実施の形態では、ユーザ端末３００から送信され、リクエスト転送手段により転送されるＨＴＴＰリクエストは、
http://<reverse proxy>/<prefix>/<path name of Web server>
となり、必ずリバースプロキシ１００を経由してウェブサーバ２００に転送されるものとする。
【００２５】
また、本実施の形態におけるリバースプロキシ１００は、ウェブサーバ２００から返送されたＨＴＴＰレスポンスに含まれるSet-Cookieヘッダを所定の形式に書き換えるSet-Cookieヘッダ書き換え部１４０と、このＨＴＴＰレスポンスに含まれるリンクやロケーションヘッダ等を書き換えるリンク・ロケーションヘッダ書き換え部１５０と、Set-Cookieヘッダ書き換え部１４０及びリンク・ロケーションヘッダ書き換え部１５０によって書き換えられたＨＴＴＰレスポンスを返送先のユーザ端末３００に送信するＨＴＴＰレスポンス送信部１６０とをさらに備える。上記のSet-Cookieヘッダ書き換え部１４０と、リンク・ロケーションヘッダ書き換え部１５０と、ＨＴＴＰレスポンス送信部１６０とで、ＨＴＴＰレスポンスをユーザ端末３００に転送するＨＴＴＰレスポンス転送手段を構成する。
【００２６】
ウェブサーバ名取得部１１０は、ＨＴＴＰリクエストに基づいてprefixの記述からこのＨＴＴＰリクエストを送信するウェブサーバ２００を特定する。但し、後述のように本実施の形態では、ＨＴＴＰリクエストのprefix部分に、リバースドＦＱＤＮで記述されたウェブサーバのドメインに関する情報が入るので、このリバースドＦＱＤＮより直接ウェブサーバ名を取得する。そしてウェブサーバ名取得部１１０は、ＨＴＴＰリクエストの送信先のウェブサーバ名を保持すると共に、このＨＴＴＰリクエストをＵＲＬ書き換え部１２０に送る。
【００２７】
ＵＲＬ書き換え部１２０は、ウェブサーバ２００においてＨＴＴＰリクエストを送信するパスを特定するためにＨＴＴＰリクエストの送信先のＵＲＬを書き換える。このＵＲＬ書き換え部１２０は、送信されたＨＴＴＰリクエストからprefixを削除して、このＨＴＴＰリクエストの送信先となるウェブサーバ２００における本来のＵＲＬを記述する。すなわちＵＲＬ書き換え部１２０は、ＨＴＴＰリクエストにおけるリバースドＦＱＤＮのドメインに関する情報を並べ替えると共に、このドメインに関する情報の構成要素を区切る文字列（“/”）を所定の文字列（“．”）に置換する。例えばＨＴＴＰリクエスト内に、ドメインに関する情報として“com/abc/www”（リバースドＦＱＤＮ）が存在していた場合には、このドメインに関する情報をウェブサーバ２００における本来のドメイン“www.abc.com”に書き換える。そして、このドメインにパスに関する情報を加えることにより、このＨＴＴＰリクエストの送信先となるウェブサーバ２００のＵＲＬ、例えば“http://www.abc.com/path1/index.html”が生成される。そしてＵＲＬ書き換え部１２０は、このＨＴＴＰリクエストをＨＴＴＰリクエスト転送部１３０に送る。
【００２８】
ＨＴＴＰリクエスト転送部１３０は、ウェブサーバ名取得部１１０によって送信先のウェブサーバ名が特定され、ＵＲＬ書き換え部１２０によって送信先のＵＲＬが書き換えられたＨＴＴＰリクエスト（２）を、当該特定されたウェブサーバ２００の所定のＵＲＬに転送する。
【００２９】
リバースプロキシ１００によって転送されたＨＴＴＰリクエストを受信したウェブサーバ２００は、このＨＴＴＰリクエストに基づいたＨＴＴＰレスポンスを、当該ＨＴＴＰリクエストを送信したユーザ端末３００に返送する。そして、このＨＴＴＰレスポンスは、リバースプロキシ１００によって中継される。
Set-Cookieヘッダ書き換え部１４０は、ウェブサーバ２００から返送されたＨＴＴＰレスポンスに含まれるSet-Cookieヘッダの書き換えを行う。このSet-Cookieヘッダ書き換え部１４０においてクッキーを書き換えるための変換規則については、図３に示す例を用いて説明する。
【００３０】
図３は、Set-Cookieヘッダ書き換え部１４０におけるSet−Cookieヘッダの書き換え規則を示す図である。図３では、Set-Cookieヘッダに含まれるドメインパラメータを削除し、パスパラメータを変換する際の変換規則を示す。ここでは、Set-Cookieヘッダに含まれるパラメータを、ケース１〜ケース４の４つの場合に分けて、それぞれの場合においてどのように変換するかについて説明する。以下に示す変換規則の例では、図２に示したウェブサーバ２００から返送されるＨＴＴＰレスポンス（３）に含まれるSet-CookieヘッダをSet-Cookieヘッダ（３）、本実施の形態における変換規則にしたがってSet−Cookieヘッダ書き換え部１４０において書き換えられたＨＴＴＰレスポンスに含まれるSet-CookieヘッダをSet-Cookieヘッダ（４）と示す。
【００３１】
ケース１： domain=<Web Server name>；path=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のＦＱＤＮがパラメータの値で、且つ、このウェブサーバ２００のパスが“/”（ルートディレクトリ）である場合には、ウェブサーバ２００からは
（３）Set-Cookie：name1=value1；domain=www.abc.com；path=/
というSet-Cookieヘッダが返送される。このSet-Cookieヘッダは、リバースプロキシ１００のSet-Cookieヘッダ書き換え部１４０において
（４）Set-Cookie：name1=value1；path=/com/abc/www/_/
と変換される。
このようにケース１に示す変換規則では、Set-Cookieヘッダのドメインパラメータ“domain=www.abc.com”が削除される。そして、このドメインパラメータの構成要素を逆順に並べ替えて、当該構成要素の区切り文字を“/”に置換して生成したリバースドＦＱＤＮ“com/abc/www”をパスパラメータに埋め込む。さらに、パスパラメータにおいてウェブサーバ２００のドメインを示す部分とウェブサーバ２００における元々のパスを示す部分との境界部分には、区切り文字として“_”が挿入される。以上のようにしてSet-Cookieヘッダが変換されて、新たなパスパラメータが生成される。ここでは、パスパラメータにおける区切り文字として“_”を用いているが、ホスト名に使用することができず、ＵＲＬの指定に用いることができる文字であれば特に問題はない。
【００３２】
ケース２：domain=<domain name of Web Server>；path=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のドメインがドメインパラメータの値（例えば“www”を除いた“abc.com”）であり、且つ、パスが“/”である場合には、ウェブサーバ２００からは
（３）Set-Cookie：name1=value1；domain=abc.com；path=/
というSet-Cookieヘッダが返送され、Set-Cookieヘッダ書き換え部１４０において
（４）Set-Cookie：name1=value1；path=/com/abc/
と変換される。つまり、ケース２に示す変換規則では、Set-Cookieヘッダのドメインパラメータ“domain=abc.com”が削除される。そして、この構成要素が逆順に並べ替えられ、且つ、この構成要素の区切り文字を置換して生成された“com/abc”がパスパラメータに埋め込まれてSet-Cookieヘッダが生成される。
【００３３】
ケース３：domain=<Web Server name>；path!=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のＦＱＤＮがドメインパラメータの値であり、且つ、パスが“/”でない場合には、ウェブサーバ２００からは
（３）Set-Cookie：name1=value1；domain=www.abc.com；path=/path1/
というSet-Cookieヘッダが返送され、Set-Cookieヘッダ書き換え部１４０において
（４）Set-Cookie：name1=value1；path=/com/abc/www/_/path1/
と変換される。つまり、ケース３に示す変換規則では、Set-Cookieヘッダのドメインパラメータ“domain=www.abc.com”が削除される。そして、この構成要素が逆順に並べ替えられ、且つ、この構成要素の区切り文字を置換して生成された“com/abc/www”と元のパスパラメータの値“/path1/”とから、新しいパスパラメータの値“/com/abc/www/_/path1/”が生成される。
【００３４】
ケース４：domain=<domain name of Web Server >；path!=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のドメインがドメインパラメータの値であり、且つ、パスが“/”でない場合である。この場合は本実施の形態ではサポートできない。しかしながらこのケースは、複数のウェブサーバ２００に同じパスが存在していることを意味し、殆ど有り得ないケースである。
【００３５】
また、リンク・ロケーションヘッダ書き換え部１５０では、このＨＴＴＰレスポンス内のリンク及びロケーションヘッダの内容を書き換える。すなわち、ＨＴＴＰリクエストに応じて発生するＨＴＴＰレスポンスがリバースプロキシ１００を経由していることを示す内容となるように、このＨＴＴＰレスポンス内のリンク及びロケーションヘッダの内容を書き換える（<RFQDN>とはリバースドＦＱＤＮのことである）。
http://<reverse proxy>/<RFQDN>/_/…
そして、Set-Cookieヘッダ書き換え部１４０及びリンク・ロケーションヘッダ書き換え部１５０において書き換えられたＨＴＴＰレスポンスをＨＴＴＰレスポンス送信部１６０に送る。このリンク・ロケーションヘッダ書き換え部１５０において書き換えられるＨＴＴＰレスポンスのデータについては、後に図８〜図１０を参照して具体的に説明する。
ＨＴＴＰレスポンス送信部１６０は、リバースドＦＱＤＮに書き換えられたSet-Cookieヘッダを含むＨＴＴＰレスポンス（４）を、ＨＴＴＰリクエストを行ったユーザ端末３００のブラウザ３００ａに送信する。
【００３６】
このようにしてＨＴＴＰレスポンスがユーザ端末３００のブラウザ３００ａにおいて受信されると、ブラウザ３００ａはＨＴＴＰリクエストにて要求されたコンテンツをウィンドウに表示する。また、ブラウザ３００ａには、ＨＴＴＰレスポンスに含まれるSet-Cookieヘッダにしたがってクッキーが設定される。
そして、次回以降、このクッキーの有効範囲のＨＴＴＰリクエストを送信する際には、このＨＴＴＰリクエストのリクエストヘッダにクッキーを埋め込んで送信する。次回以降にリクエストヘッダにクッキーが埋め込まれたＨＴＴＰリクエストを送信する例については、以下に示す図６を用いて説明する。
【００３７】
図４は、本実施の形態のネットワークシステムにおけるデータの流れを示す図である。
図４に示すように、このネットワークシステムは、例えば、ウェブサーバ２０１（ホスト名：“www.abc.com”）、ウェブサーバ２０２（ホスト名：“www2.abc.com”）、ウェブサーバ２０３（ホスト名：“www3.sub.abc.com”）、ウェブサーバ２０４（ホスト名：“www.xyz.com”）の複数のウェブサーバ２００と、リバースプロキシ１００（ホスト名：“rproxy.ijk.com”）と、ユーザ端末３００とから構成されるものとする。
【００３８】
図４に示すネットワークシステムにおいて、ユーザ端末３００からリバースプロキシ１００を介して行われたＨＴＴＰリクエストに対するＨＴＴＰレスポンスに含まれるSet-Cookieヘッダについて説明する。
このとき、ウェブサーバ２０１（“www.abc.com”）からは、ユーザ端末３００に対してクッキーを設定するための、以下の２つのSet−Cookieヘッダ
（Ａ１）Set-Cookie：name1=value1；domain=www.abc.com；path=/；
Set-Cookie：name2=value2；domain= abc.com；path=/；
を含むＨＴＴＰレスポンスが返送されるものとする。
また、ウェブサーバ２０３（“www3.sub.abc.com”）からは、ユーザ端末３００に対してクッキーを設定するための、以下のSet−Cookieヘッダ
（Ｃ１）Set-Cookie：name3=value3；domain=sub.abc.com；path=/；
を含むＨＴＴＰレスポンスが返送されるものとする。
【００３９】
上記の（Ａ１），（Ｃ１）で示した場合におけるクッキー“name1”,“name2”,“name3”それぞれの有効範囲となるウェブサーバ２００を図５に示す。図５に示すように、“name1”によるクッキーの有効範囲には、ウェブサーバ２０１（“www.abc.com”）が含まれる。また、“name2”によるクッキーの有効範囲には、ウェブサーバ２０１（“www.abc.com”）、ウェブサーバ２０２（“www2.abc.com”）、及びウェブサーバ２０３（“www3.sub.abc.com”）が含まれる。さらに、“name3”によるクッキーの有効範囲には、ウェブサーバ２０３（“www3.sub.abc.com”）が含まれる。
【００４０】
ところで、これら（Ａ１），（Ｃ１）に示したSet-Cookieヘッダは、リバースプロキシ１００のSet-Cookieヘッダ書き換え部１４０によって以下のように変換される。
すなわちSet-Cookieヘッダ
（Ａ１）Set-Cookie：name1=value1；domain=www.abc.com；path=/；
は、上記のケース１の変換規則により、
（Ａ２）Set-Cookie：name1=value1；path=/com/abc/www/_/；
となる。
また、Set-Cookieヘッダ
（Ａ１）Set-Cookie：name2=value2；domain= abc.com；path=/；
は、上記のケース２の変換規則により、
（Ａ２）Set-Cookie：name2=value2；path=/com/abc/；
となる。
さらに、Set-Cookieヘッダ
（Ｃ１）Set-Cookie：name1=value1；domain=www.abc.com；path=/；
は、上記のケース２の変換規則により、
（Ｃ２）Set-Cookie：name3=value3；path=/com/abc/sub/；
となる。
【００４１】
よって、その後のユーザ端末３００から各ウェブサーバにアクセスする際、ＨＴＴＰリクエストには、それぞれ図６に示すようなクッキーが埋め込まれる。
すなわち、ユーザ端末３００からウェブサーバ２０１へのＨＴＴＰリクエスト（Ａ３）のリクエストヘッダには、図５に示したクッキーの有効範囲に対応するクッキーが埋め込まれ
http://rproxy.ijk.com/com/abc/www/_/…
Cookie：name1=value1；name2=value2；
として送信される。
また、ユーザ端末３００からウェブサーバ２０２へのＨＴＴＰリクエスト（Ｂ３）のリクエストヘッダには、図５に示したクッキーの有効範囲に対応するクッキーが埋め込まれ
http://rproxy.ijk.com/com/abc/www2/_/…
Cookie：name2=value2；
として送信される。
さらに、ユーザ端末３００からウェブサーバ２０３へのＨＴＴＰリクエスト（Ｃ３）のリクエストヘッダには、図５に示したクッキーの有効範囲に対応するクッキーが埋め込まれ
http://rproxy.ijk.com/com/abc/sub/www3/_/…
Cookie：name2=value2；name3=value3；
として送信される。
またさらに、ユーザ端末３００からウェブサーバ２０４へのＨＴＴＰリクエスト（Ｄ３）のリクエストヘッダは
http://rproxy.ijk.com/com/xyz/www/_/…
として送信されるが、このＨＴＴＰリクエスト（Ｄ３）に対応するクッキーは存在しないのでリクエストヘッダにクッキーは埋め込まれない。
以上のように、図６に示した２回目以降に送信されるＨＴＴＰリクエストに含まれるクッキーは、図５に示したクッキーの有効範囲となるウェブサーバ２００に一致している。換言すれば、リバースプロキシ１００を介してクッキーが透過的に扱われているといえる。
【００４２】
これら（Ａ３）〜（Ｃ３）のＨＴＴＰリクエストは、リバースプロキシ１００のウェブサーバ名取得部１１０及びＵＲＬ書き換え部１２０において所定の処理を経て（Ａ４）〜（Ｃ４）に変換される。そしてＨＴＴＰリクエスト転送部１３０によって、ＨＴＴＰリクエスト（Ａ４）はウェブサーバ２０１に、ＨＴＴＰリクエスト（Ｂ４）はウェブサーバ２０２に、ＨＴＴＰリクエスト（Ｃ４）はウェブサーバ２０３にそれぞれ転送される。
また同様にして、ＨＴＴＰリクエスト転送部１３０によって、（Ｄ３）のＨＴＴＰリクエストは（Ｄ４）としてウェブサーバ２０４に転送される。
【００４３】
ところで、通常のＨＴＴＰリクエストにおいて使用されるポート番号は８０番であるが、本実施の形態では、ＨＴＴＰリクエストを送信する送信先のウェブサーバ２００のポート番号がデフォルトのポート番号ではなく、明示的に指定する必要がある場合は、例えば以下のようにポート番号を指定すればよい。
http://<reverse proxy>/<RFQDN>/_<port>/<path name of Web server>
このようにして“<port>”部分にウェブサーバ２００のポート番号を指定しておけば、ウェブサーバ２００において通常とは異なるポートがＨＴＴＰリクエスト用のポートとして用いられている場合であっても、ＨＴＴＰリクエストを当該ウェブサーバ２００に送信することができる。
【００４４】
本実施の形態では、<prefix>として“<RFQDN>_”を用いているが、<RFQDN>の前に固定の文字列、例えば“xxx/”が付いていてもクッキーを透過的に扱うことができる。つまり、ブラウザ３００ａがリバースプロキシ１００を経由してウェブサーバ２０１（“www.abc.com”）の“/index.html”にアクセスする場合は、以下のようになる。
http://<reverse proxy>/xxx/com/abc/www/_/index.html
そして、ウェブサーバ２０１が以下のようなSet-Cookieヘッダを返した場合、
Set-Cookie：name1=value1；domain=abc.com；path=/；
リバースプロキシ１００は、このSet-Cookieヘッダを以下のように変換してユーザ端末３００に送る。
Set-Cookie：name1=value1；path=/xxx/com/abc/；
【００４５】
本実施の形態では、“www.abc.com”を変換することにより、“com/abc/www”とした。しかし、ドメインパラメータを指定する場合において、“.com”や“.net”、又は“.co.jp”といったトップレベルドメインだけの指定を行うことはできず、常に１つ下の階層（サブドメイン）からでなければ、このドメインパラメータの指定を行うことができない。つまりドメインパラメータの指定は、“abc.com”や“abc.net”、又は“abc.co.jp”というように、１つ下の階層から行わなければならない。よって、リバースプロキシ１００へのアクセスパスは、最低限指定すべきドメインを１つにまとめて、以下のようにしても良い。
（図４、Ａ３）http://<reverse proxy>/abc-com/www/_/index.html
（図４、Ｃ３）http://<reverse proxy>/abc-com/sub/www3/_/index.html
これらのＨＴＴＰリクエストを受け取ったリバースプロキシ１００は、区切り文字“_”の前までの文字列から転送先のウェブサーバ名をそれぞれ、“www.abc.com”、“www3.sub.abc.com”と判断し、それぞれのウェブサーバ２００に対して以下のＨＴＴＰリクエストを送る。
（図４、Ａ４）http://www.abc.com/index.html
（図４、Ｃ４）http://www3.sub.abc.com/index.html
また、これらのウェブサーバ２００が以下のようなSet-Cookieヘッダを返したとする。
（図４、Ａ１）Set-Cookie：id1=001；domain=www.abc.com；path=/；
（図４、Ｃ１）Set-Cookie：id1=001；domain=sub.abc.com；path=/；
リバースプロキシ１００は、このSet-Cookieヘッダを以下のように変換する。
（図４、Ａ２）Set-Cookie：id1=001；path=/abc-com/www/_/；
（図４、Ｃ２）Set-Cookie：id1=001；path=/abc-com/sub/；
このような<prefix>を用いてもクッキーを透過的に扱うことができる。
【００４６】
また、図４を用いて説明した例では、リバースプロキシ１００が返すSet-Cookieヘッダ内でドメインパラメータを指定していないが、このような場合Set-Cookieヘッダは、ＨＴＴＰレスポンスを送信したサーバを示す。そこで図４に示した例において、例えば
Set-Cookie：name1=value1；path=/com/abc/www/_/；domain=<reverse proxy>といったように、Set-Cookieヘッダのドメインパラメータを自装置のサーバ名に置換して、このリバースプロキシ１００のサーバ名を明示的に指定しても良い。
【００４７】
図７は、本実施の形態のリバースプロキシ１００における処理を示すフローチャートである。図７に示すフローチャートでは、リバースプロキシ１００において、ユーザ端末３００から送信されたＨＴＴＰリクエスト、及びウェブサーバ２００から返送されたＨＴＴＰレスポンスに対して行われる処理について説明する。また、以下に示す各処理において用いられるデータ（ＨＴＴＰレスポンス）を図８〜図１０に示す。
ユーザ端末３００からクッキーが埋め込まれたＨＴＴＰリクエストが送信されると、このＨＴＴＰリクエストは、リバースプロキシ１００によって受信され、ウェブサーバ名取得部１１０に渡される（ステップ７０１）。以下では、ステップ７０１において受信されたＨＴＴＰリクエストが
（Ｒｅｑ１）GET /com/abc/www/_/index.html HTTP/1.1
であるものとして説明する。
【００４８】
ステップ７０１において受信されたＨＴＴＰリクエストからは、ウェブサーバ名取得部１１０によって、prefixに基づいてウェブサーバ名が取得される（ステップ７０２）。これにより、このＨＴＴＰリクエストの送信先のウェブサーバ２００が特定される。ステップ７０２においてＨＴＴＰリクエストの送信先のウェブサーバ名が特定されたＨＴＴＰリクエストは、ＵＲＬ書き換え部１２０に送信される。ＵＲＬ書き換え部１２０では、ステップ７０２においてウェブサーバ名取得部１１０において特定された情報に基づいてＵＲＬの書き換えを行う（ステップ７０３）。すなわちステップ７０３においてＵＲＬ書き換え部１２０は、ＨＴＴＰリクエストの送信先となるウェブサーバ２００における本来のＵＲＬとパス“/www.abc.com/index.html”を取得する。ＨＴＴＰリクエストの送信先のウェブサーバ２００（“www.abc.com”）、及びこのウェブサーバ２００内におけるＵＲＬ（“www.abc.com”のルートディレクトリの“index.html”）を特定されたＨＴＴＰリクエスト
（Ｒｅｑ２）GET /index.html HTTP/1.1
は、ＨＴＴＰリクエスト転送部１３０に送信される。そしてこのＨＴＴＰリクエストは、ＨＴＴＰリクエスト転送部１３０によって、ステップ７０２で特定されたウェブサーバ２００に転送される（ステップ７０４）。
【００４９】
ＨＴＴＰリクエストを受け取ったウェブサーバ２００は、リバースプロキシ１００から転送されたＨＴＴＰリクエストに応じたＨＴＴＰレスポンスが、ＨＴＴＰリクエストを行ったユーザ端末３００に対して送信される。このＨＴＴＰレスポンスには、後々行われるＨＴＴＰリクエストにおいてユーザの状態を通知するためのCookieヘッダが埋め込まれて返送される。ウェブサーバ２００から返送されたＨＴＴＰレスポンスは、一旦リバースプロキシ１００を中継してユーザ端末３００に返送される。すなわち、ウェブサーバ２００から返送されたＨＴＴＰレスポンスは、リバースプロキシ１００によって受信され、Set-Cookieヘッダ書き換え部１４０に渡される（ステップ７０５）。
【００５０】
ステップ７０５において受信されるＨＴＴＰレスポンスの一例を図８に示す。図８に示すように、このＨＴＴＰレスポンスにはSet-Cookieヘッダ
Set-Cookie：sessionid=001；path=/；domain=abc.com；
が含まれている。そしてこのSet-Cookieヘッダには、ユーザを特定するｉｄに相当する“sessionid=001”と、このSet-Cookieヘッダによって設定されたクッキーをブラウザ３００ａが送り返す返送先のウェブサーバ２００のＵＲＬ（パス）を特定する“path=/”と、返送先のウェブサーバのドメインを特定する“domain=abc.com”とが含まれる。また、このＨＴＴＰレスポンスは、Set-Cookieヘッダの他にもウェブサーバ２００から返送される種々のヘッダ情報を含む。
【００５１】
リバースプロキシ１００においてＨＴＴＰレスポンスが受信されたら、Set-Cookieヘッダ書き換え部１４０では、ＨＴＴＰレスポンス内にSet-Cookieヘッダが存在しているか否かの判断が行われる（ステップ７０６）。ステップ７０６において、ＨＴＴＰレスポンス内にSet-Cookieヘッダが存在していると判断された場合には、Set-Cookieヘッダ書き換え部１４０においてSet-Cookieヘッダの書き換えが行われる（ステップ７０７）。ステップ７０７におけるSet-Cookieヘッダの書き換えは、図３に示した変換規則にしたがって行われる。すなわち、ドメインパラメータを削除し、このドメインを構成する構成要素を逆順に並べ替え、さらにこの構成要素を区切る区切り文字“.”を“/”として置換したものを当該Set-Cookieヘッダのパスパラメータに埋め込む。ステップ７０６において、ＨＴＴＰレスポンス内にSet-Cookieヘッダが存在していないと判断された場合には、ステップ７０７の処理は省略される。
【００５２】
ステップ７０７においてSet-Cookieヘッダが書き換えられたＨＴＴＰレスポンスの一例を図９に示す。図９に示すように、ステップ７０７において書き換えられたSet-Cookieヘッダは
Set-Cookie：sessionid=001；path=/com/abc/;
となる。上記のSet-Cookieヘッダは、図３に示した変換規則にしたがって書き換えられていることがわかる。
【００５３】
ステップ７０７においてSet-CookieヘッダがリバースドＦＱＤＮに書き換えられたＨＴＴＰレスポンスは、Set-Cookieヘッダ書き換え部１４０からリンク・ロケーションヘッダ書き換え部１５０に送信される。そして、このＨＴＴＰリクエストを受信したリンク・ロケーションヘッダ書き換え部１５０では、コンテンツ内のリンク及びロケーションヘッダの書き換えを行う（ステップ７０８）。
【００５４】
ステップ７０８において、リンクが書き換えられた状態のＨＴＴＰレスポンスの一例を図１０に示す。ステップ７０８において書き換えられたリンク先の指定部分は、図８及び図９に示した
“/menu1.html”
“/menu2.html”
“/menu3.html”
から、図１０に示す
“/com/abc/www/_/menu1.html”
“/com/abc/www/_/menu2.html”
“/com/abc/www/_/menu3.html”
といったように、リバースドＦＱＤＮが付与された絶対パスに書き換えられる。
【００５５】
以上のようにして書き換えられたブラウザが認識可能な形式のSet-Cookieヘッダを含むＨＴＴＰレスポンスは、ＨＴＴＰレスポンス送信部１６０によりステップ７０１において受信されたＨＴＴＰリクエストを送信したユーザ端末３００に対して送信される（ステップ７０９）。そして、ユーザ端末３００のブラウザには、このＨＴＴＰレスポンス及びこのＨＴＴＰレスポンスとリンクしたデータやファイルに基づいたコンテンツが表示され、ＨＴＴＰレスポンスに含まれるSet-Cookieヘッダに基づいて、所定の有効範囲に対するクッキーがブラウザに保持される。
【００５６】
以上のように本実施の形態におけるリバースプロキシ１００は、ドメインパラメータを削除し、パスパラメータを書き換えた Set-Cookieヘッダをユーザ端末３００に送信する。そうすることによりユーザ端末３００のブラウザ３００ａには、リバースプロキシ１００を介して返送されたＨＴＴＰレスポンスに含まれるSet-Cookieヘッダに基づいてクッキーが設定され、保持される。
そして次回以降、ブラウザ３００ａが送信するＨＴＴＰリクエストにCookieヘッダが付いている場合、リバースプロキシ１００は、このCookieヘッダをそのまま対応するウェブサーバ２００に転送すれば、そのCookieはウェブサーバ２００がSet-Cookieヘッダ内で指定したドメイン、パスに合致している範囲にのみ送られることになる。
【００５７】
【発明の効果】
以上説明したように、本発明によれば、リバースプロキシを経由してサーバへアクセスするネットワークシステムにおいて、サーバによって設定されたクッキーを透過的に扱うようにすることができる。
【００５８】
また、本発明によれば、サーバの設定したクッキーを透過的に扱うためにSet-Cookieを書き換える機能を備えたリバースプロキシを提供することができる。
【図面の簡単な説明】
【図１】 本実施の形態におけるネットワークシステムの構成を示す図である。
【図２】 本実施の形態におけるリバースプロキシの機能を示すブロック図である。
【図３】 本実施の形態におけるSet-Cookieヘッダ書き換え部におけるクッキーの変換規則を示す図である。
【図４】 本実施の形態のネットワークシステムにおけるデータの流れを示す図である。
【図５】 本実施の形態の変換規則におけるクッキーの有効範囲となるウェブサーバの一例を示す図である。
【図６】 各ケースに対応したリバースドＦＱＤＮのSet-Cookieヘッダの一例を示す図である。
【図７】 本実施の形態のリバースプロキシにおける処理を示すフローチャートである。
【図８】 本実施の形態のリバースプロキシにおいて受信されるレスポンスデータの一例を示す図である。
【図９】 本実施のリバースプロキシにおいてSet-Cookieヘッダが書き換えられたレスポンスデータの一例を示す図である。
【図１０】 本実施の形態のリバースプロキシから送信されるレスポンスデータの一例を示す図である。
【図１１】 ウェブサーバから送信されるSet-Cookieヘッダによって決められるクッキーの有効範囲と、このクッキーの有効範囲であるウェブサーバに送信されるＨＴＴＰリクエスト及びクッキーの一例を示す図である。
【図１２】 リバースプロキシにおいて管理されるテーブルを示す図である。
【符号の説明】
１００…リバースプロキシ、１１０…ウェブサーバ名取得部、１２０…ＵＲＬ書き換え部、１３０…ＨＴＴＰリクエスト転送部、１４０…Set-Cookieヘッダ書き換え部、１５０…リンク・ロケーションヘッダ書き換え部、１６０…ＨＴＴＰレスポンス送信部、２００…ウェブサーバ、３００…ユーザ端末、４００…ネットワーク、５００…ネットワーク
【発明の属する技術分野】
本発明は、ネットワーク上でサーバと外部ネットワークとの間に介在させるリバースプロキシに関し、特にサーバがクッキーを設定する場合のリバースプロキシの処理等に関する。
【０００２】
【従来の技術】
ネットワークにおいて種々のサービスを提供するサーバのセキュリティを強化するため、ネットワーク上にリバースプロキシを設置することが行われる。リバースプロキシとは、サーバに代わって当該サーバへの要求を受信し中継するプロキシサーバである。すなわち、当該サーバにアクセスしようとしたユーザは全てリバースプロキシを経由することになるため、当該サーバが外部から直接アクセスを受けることがなくなる。
【０００３】
リバースプロキシを経由してサーバへアクセスする場合、アクセス要求（リクエスト）には一般に次のフォーマットが用いられる。なお、以下の例では通信プロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）を用い、ウェブサーバへアクセスする場合について説明する。
（１）http://<reverse proxy>/<prefix>/<path name of Web server>
（２）http://<web server>/<path name of Web server>
リバースプロキシは、<prefix>とウェブサーバ名とを対応付けた図１２に示すようなテーブルを管理している。そして、（１）のフォーマットのリクエストを受け取ると、図１２のテーブルを参照し、リクエスト中の<prefix>に対応するウェブサーバに対して（２）のフォーマットのリクエストを送る。
【０００４】
ところで、ＨＴＴＰリクエストは、ステートレスつまり各リクエストが独立であるため、ウェブサーバは、１人のユーザからの連続するリクエストであっても１つ１つ独立したリクエストと認識する。そこで、リクエスト間で状態を保持するためにクッキー（Cookie）が導入されている。
クッキーはウェブサーバがブラウザに設定するものであり、例えば以下のようにしてユーザを追跡することができる。
まず、ウェブサーバがユーザからのリクエストに対してレスポンスを返す際に、レスポンス内に、
Set-Cookie: id=001
のようなSet-Cookie（セットクッキー）をヘッダに埋め込む。これにより、その後の当該ユーザからの全てのリクエストには、リクエストヘッダ内に、
Cookie: id=001
というクッキーが埋め込まれる。この情報に基づいて、当該ユーザがどのページにアクセスしたかを追跡することができる。
【０００５】
ここで、上記のSet-Cookieを埋め込んだヘッダ（以下、Set-Cookie ヘッダ）は、以下のようなフォーマットを持つ。
Set-Cookie: <name>=<value>; domain=<domain>; path=<path>;（その他）
ドメイン（domain）、パス（path）の指定により、これを受け取ったブラウザがクッキーを送り返す範囲を制限している。つまり、ドメインで指定された範囲内のウェブサーバにおいて、パスで指定されているディレクトリ（directory）以下のアクセスに対してのみクッキーが送り返されることとなる。
【０００６】
【発明が解決しようとする課題】
しかし、リバースプロキシが設置されたネットワークシステムにおいて、リバースプロキシからサーバへ送られたリクエスト（例えば上述した（２）のフォーマットのリクエスト）に対する当該サーバからのレスポンス内にSet-Cookieヘッダがあった場合、このレスポンスをそのままリバースプロキシがリクエストを行ったブラウザ（ユーザ端末）へ返すと、一般的に当該ブラウザはこのSet-Cookieを正しく受け取ることができない。
その理由は、Set-Cookieはドメイン、パスを特定するパラメータによってその有効範囲を指定しているが、サーバ本来のドメイン及びパスと、リバースプロキシを通したときの当該サーバのドメイン及びパスが異なるためである。例えば、ウェブサーバが、自身が属するドメインの値をドメインパラメータに設定してSet-Cookieを設定した場合において、ブラウザから認識できるリバースプロキシがSet-Cookieで指定されているドメインに存在しない場合は、ブラウザはこのSet-Cookieを無視してしまうためである。
【０００７】
そこで本発明は、リバースプロキシを経由してサーバへアクセスするネットワークシステムにおいて、サーバによって設定されたクッキーを透過的に扱うようにすることを目的とする。
また本発明は、サーバの設定したクッキーを有効に使用するためにSet-Cookieを書き換える機能を備えたリバースプロキシを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成する本発明は、次のようなネットワークシステムによって実現される。すなわち、このネットワークシステムは、ネットワーク上に設けられた複数のウェブサーバと、この複数のウェブサーバに対する外部からのアクセスを中継するリバースプロキシとを備え、このネットワークシステムにおいてウェブサーバは、ネットワークに接続された所定の端末から送信されたリクエストに応じて端末の状態を保持するための情報を含むレスポンスをこの端末に返送し、リバースプロキシは、このレスポンスに含まれる端末の状態を保持するための情報を、この端末がネットワークの構成として認識可能な形式に変換して返送する。そして、リバースプロキシは、端末の状態を保持するための情報に含まれるウェブサーバのドメインを指定するドメインパラメータを削除し、ドメインパラメータを構成する構成要素の並び順を逆順に並べ替えて、この情報に含まれるウェブサーバにおけるパスパラメータに埋め込む。
【０００９】
また、本発明は、次のような機能構成を有するリバースプロキシによって実現される。ウェブサーバからユーザ端末へのデータの送信を中継するリバースプロキシは、ウェブサーバからユーザ端末に返送されたデータを受信すると共に、このデータに含まれるSet-Cookieヘッダのドメイン、パスの記述をユーザ端末が認識可能な形式に書き換えるヘッダ書き換え部と、このヘッダ書き換え部によって書き換えられたデータをユーザ端末に送信するデータ送信部とを備える。また、このリバースプロキシは、このデータに含まれるリンク及びロケーションのドメイン及びパスをヘッダ書き換え部によって書き換えられたドメインの記述を含むパスに合わせて書き換えるリンク・ロケーション書き換え部をさらに備える。
【００１０】
さらに、本発明は、次のような機能構成を有するリバースプロキシによって実現される。ユーザ端末からウェブサーバへのリクエストの送信を中継するリバースプロキシは、受信されたリクエストの記述を変換して得られる情報（ドメインに関する情報）に基づいてネットワーク上に配置された複数のサーバのうちこのリクエストを送信するウェブサーバを特定するウェブサーバ名取得部と、このウェブサーバ名取得部にて特定されたウェブサーバに基づいて、このリクエストによるアクセス先をこのウェブサーバにおけるＵＲＬに書き換えるＵＲＬ書き換え部と、ウェブサーバのＵＲＬにこのリクエストを転送するリクエスト転送部とを備える。
【００１１】
またさらに、本発明は、次のようなコンピュータ装置を提供することができる。すなわち、端末とサーバとの間におけるＨＴＴＰリクエストの送信及びＨＴＴＰレスポンスの返送を中継するコンピュータ装置は、この端末のブラウザから送信されたクッキーとＨＴＴＰリクエストとを中継してこのＨＴＴＰリクエストの送信先のサーバに転送するＨＴＴＰリクエスト転送手段と、このＨＴＴＰリクエストに応じてこのサーバから返送されたＨＴＴＰレスポンスを受信し、セットクッキーヘッダに記述されたドメインを削除してこのドメインを構成する構成要素の並び順を逆順に並べ替えて、セットクッキーヘッダに記述されたパスに埋め込んでこの端末に転送するＨＴＴＰレスポンス転送手段とを備える。ここで、このＨＴＴＰリクエスト転送手段は、ウェブサーバがデフォルトのポート以外を使用している場合は、ブラウザのリバースプロキシに対するアクセスパス内にウェブサーバのポート番号を指定してアクセスする。また、この前記ＨＴＴＰレスポンス転送手段は、ＨＴＴＰレスポンスに応じて所定の固定文字列をセットクッキーヘッダに付け加えて端末に転送する。さらに、ＨＴＴＰレスポンス転送手段は、ドメインの構成要素の並び順を逆順に並べ替える際に、このドメインを特定するのに必要な構成要素を１つに纏めて端末に転送する。またさらに、ＨＴＴＰレスポンス転送手段は、サーバのセットクッキーヘッダ内のドメインパラメータを自装置のサーバ名に置換して端末に転送する。
【００１２】
さらにまた、本発明は、次のようなデータ処理方法を提供することができる。すなわち、第１のコンピュータ装置と第２のコンピュータ装置とのデータの送受信を中継するコンピュータ装置におけるデータ処理方法は、第１のコンピュータ装置から第２のコンピュータ装置に対して送信されたレスポンスを受信するステップと、このレスポンスにセットクッキーヘッダが含まれているか否かを判断するステップと、このレスポンスにセットクッキーヘッダが含まれている場合には、セットクッキーヘッダに基づいて第２のコンピュータ装置に設定されるクッキーがこの第２のコンピュータ装置において認識可能な形式となるようにセットクッキーヘッダを書き換えるステップと、このセットクッキーヘッダが書き換えられたレスポンスを第２のコンピュータ装置に送信するステップとを含む。
また、第１のコンピュータ装置と第２のコンピュータ装置とのデータの送受信を中継するコンピュータ装置におけるデータ処理方法は、第２のコンピュータ装置から送信されたリクエストを受信し、
このリクエストの情報を変換して得られる情報に基づいてこのリクエストを送信する第１のコンピュータ装置を特定するステップと、このリクエストによるアクセス先を特定された第１のコンピュータ装置におけるＵＲＬに書き換えるステップと、特定されたこの第１のコンピュータ装置のＵＲＬにリクエストを送信するステップとを含む。
【００１３】
ここで本発明は、上述した所定のデータ処理を行う方法の各ステップによる処理、及び各部の機能において実現される処理をコンピュータを制御して実行するプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
【００１４】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
図１は、本実施の形態におけるネットワークシステムの構成を示す図である。図１に示すように、本実施の形態におけるネットワークシステムは、外部からのリクエストに応じたコンテンツを提供すると共にクッキーを返送するウェブサーバ２００と、このウェブサーバ２００へのリクエストの送信及びこのリクエストに対するウェブサーバ２００からのレスポンスを例えばＬＡＮ網からなるネットワーク４００を介して中継するリバースプロキシ１００と、このリバースプロキシ１００に例えばインターネット網からなるネットワーク５００を介して接続され、ウェブサーバ２００へのリクエストを送信すると共にウェブサーバ２００からのレスポンスを受信するユーザ端末３００とを備える。
図示するように、本実施の形態におけるネットワークにおいてウェブサーバ２００は、異なるドメインを有する複数のウェブサーバ２０１，２０２などから構成される。また図示するように、このウェブサーバ２００には、ブラウザ３０１ａ，３０２ａを備えたユーザ端末３０１，３０２などの複数の端末から任意にアクセスすることができる。以下では、このウェブサーバ２００にアクセスする端末が物理的に同じ端末であっても、ログインするユーザに応じて異なる端末であるものとみなす。
【００１５】
以下、本実施の形態では、ウェブサーバ２００とユーザ端末３００との通信プロトコルとしてＨＴＴＰを用い、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受信を行う場合について説明する。
図１に示したウェブサーバ２００は、例えばサーバとして外部からのアクセス負荷に耐え得る機能を備えたコンピュータ装置などからなる。このウェブサーバ２００は、ユーザ端末３００から送信されたＨＴＴＰリクエストに対してデータやファイル（ＨＴＴＰレスポンス）を返送することにより、このユーザ端末３００にＨＴＴＰリクエストに応じたコンテンツを提供する。そしてこのウェブサーバ２００は、ユーザ端末３００にＨＴＴＰレスポンスを返送する際、このＨＴＴＰレスポンス内にSet-Cookieヘッダを埋め込んで返送する。ウェブサーバ２００から返送されるＨＴＴＰレスポンスは、一旦、ウェブサーバ２００とユーザ端末３００との間に設けられたリバースプロキシ１００によって受信される。本実施の形態では、このウェブサーバ２００において埋め込まれたSet-Cookieヘッダを含むＨＴＴＰレスポンスは、リバースプロキシ１００において所定の形式に変換される。
【００１６】
リバースプロキシ１００は、例えばウェブサーバ２００とユーザ端末３００とをＨＴＴＰリクエスト及びＨＴＴＰレスポンスを中継するネットワーク機能を備えたコンピュータ装置などからなる。このリバースプロキシ１００は、ユーザ端末３００からのＨＴＴＰリクエストを中継して、このＨＴＴＰリクエストにて特定されるウェブサーバ２００にＨＴＴＰリクエストを転送する。さらにこのリバースプロキシ１００は、転送したＨＴＴＰリクエストに応じてウェブサーバ３００から返信されてきたＨＴＴＰレスポンスを中継する。
ここで、本実施の形態におけるリバースプロキシ１００は、ウェブサーバ２００から返送されたSet-Cookieヘッダを含むＨＴＴＰレスポンスを受信して、このＨＴＴＰレスポンス内のSet-Cookieヘッダを所定の形式に変換する。さらにこのＨＴＴＰレスポンスに含まれるリンク・ロケーションヘッダの書き換えを行う。そして、Set-Cookieヘッダ、及びリンク・ロケーションヘッダが書き換えられたＨＴＴＰレスポンスを、ＨＴＴＰリクエストを行ったユーザ端末３００に対して送信する。リバースプロキシ１００において実現されるこれらの機能の詳細については後述する。
【００１７】
またユーザ端末３００は、例えばパーソナルコンピュータやワークステーションなどからなる。これらのユーザ端末３００は、キーボードやマウス等の操作部及びディスプレイ等の表示部を有する。また、このユーザ端末３００は、プログラム制御に応じて動作するブラウザ３００ａを備える。このブラウザ３００ａは、操作部における操作に応じて表示部にブラウザウィンドウ（画面）を表示すると共に、種々のウェブサーバ２００によって設定されたクッキーを管理する。そしてブラウザ３００ａは、このブラウザウィンドウに対して所定の操作が行われることにより、ネットワーク接続されたウェブサーバ２００に対して例えばＨＴＴＰリクエストを送信する。ユーザ端末３００は、このＨＴＴＰリクエストに応じてウェブサーバ２００から返送されたＨＴＴＰレスポンスに基づいて、ブラウザ３００ａ上にコンテンツを表示する。
さらにこのブラウザ３００ａには、ＨＴＴＰレスポンスに埋め込まれてウェブサーバ２００から返送されたSet-Cookieヘッダに基づいてクッキーが設定される。ブラウザ３００ａはこのクッキーを保持し、次回以降にこのクッキーの有効範囲となるウェブサーバ２００にＨＴＴＰリクエストを送信する際には、このＨＴＴＰリクエストにクッキーを埋め込んで送信する。そうすると、このクッキーを含むＨＴＴＰリクエストを受信したウェブサーバ２００は、同じユーザ端末３００から送信されるＨＴＴＰリクエストの関連性を保つと共に、ユーザ端末３００の状態を保持することができるようになる。
【００１８】
以下では、リバースプロキシ１００の機能について述べるが、ここで、ユーザ端末３００から送信されたＨＴＴＰリクエストに基づいてウェブサーバ２００から返送されるＨＴＴＰレスポンスに含まれるSet-Cookieヘッダについて説明する。
ＨＴＴＰレスポンスに含まれるSet-Cookieヘッダには、ドメイン、パスパラメータが記述されている。そして、この情報によって、ユーザ端末３００のブラウザ３００ａには、クッキーの有効範囲が設定される。以下、図１１を用いてウェブサーバ２００からユーザ端末３００に返送されるＨＴＴＰレスポンスに含まれるSet-Cookieヘッダ、及びユーザ端末３００からウェブサーバ２００に送信されるＨＴＴＰリクエストのリクエストヘッダに埋め込まれるクッキーについて説明する。
【００１９】
図１１は、ウェブサーバ２００から送信されるSet-Cookieヘッダによって決められるクッキーの有効範囲と、このクッキーの有効範囲であるウェブサーバ２００に送信されるＨＴＴＰリクエスト及びクッキーの一例を示す図である。
図示した例では、ネットワーク上に、ウェブサーバ２０１（ドメイン：“www.sub.abc.com”）、ウェブサーバ２０２（ドメイン：“www2.sub.abc.com”）、ウェブサーバ２０３（ドメイン：“www3.abc.com”）、ウェブサーバ２０４（ドメイン：“www.xyz.com”）の複数のウェブサーバ２００が配置されている。そして、このウェブサーバ２００との間でＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受信を行うユーザ端末３００がネットワークを介して接続されている。ウェブサーバ２０１は、ユーザ端末３００から送信されたＨＴＴＰリクエストに応じて、
(１)Set-Cookie:name1=value1；domain=www.sub.abc.com；path=/；
Set-Cookie:name2=value2；domain=www.sub.abc.com；path=/path1/；
Set-Cookie:name3=value3；domain=sub.abc.com；path=/；
Set-Cookie:name4=value4；domain=abc.com；path=/；
というSet-Cookieヘッダ（１）を含むＨＴＴＰレスポンスを返送する。
そうすると、ユーザ端末３００のブラウザ３００ａには、このSet-Cookieヘッダ（１）に基づいてクッキーが設定され、保持される。このSeｔ−Cookieヘッダ（１）に基づいて設定されるクッキーの有効範囲は、
name1：www.sub.abc.com；
name2：www.sub.abc.com/path1；
name3：www.sub.abc.com；www2.sub.abc.com；
name4：www.sub.abc.com；www2.sub.abc.com；www3.sub.abc.com；
である。
【００２０】
図１１に示した例では、ユーザ端末３００からウェブサーバ２０１にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（２）GET /index.html
Cookie：name1=value1；name3=value3；name4=value4；
が埋め込まれて送信される。
ユーザ端末３００からウェブサーバ２０１のディレクトリ（“/path1/”）にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（３）GET /path1/index.html
Cookie：name1=value1；name2=value2；name3=value3；name4=value4；
が埋め込まれて送信される。
ユーザ端末３００からウェブサーバ２０２にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（４）GET /index.html
Cookie：name3=value3；name4=value4；
が埋め込まれて送信される。
ユーザ端末３００からウェブサーバ２０３にＨＴＴＰリクエストを送信する場合、このＨＴＴＰリクエストのリクエストヘッダには、ブラウザ３００ａに保持されたクッキーの有効範囲に基づいて
（５）GET /index.html
Cookie：name4=value4；
が埋め込まれて送信される。
また、ユーザ端末３００からウェブサーバ２０４にＨＴＴＰリクエストを送信する場合についてだが、このウェブサーバ２０４を有効範囲とするクッキーは存在しないので、このＨＴＴＰリクエストのリクエストヘッダにクッキーは埋め込まれない。すなわち
（６）GET /index.html
だけが送信される。
以上のように、ユーザ端末３００からウェブサーバ２００にＨＴＴＰリクエストを送信する際、このＨＴＴＰリクエストのリクエストヘッダには、それぞれのクッキーの有効範囲に基づいて、ＨＴＴＰリクエストの送信先となるウェブサーバ２００に応じたクッキーが埋め込まれて送信されていた。
【００２１】
上記のように、ＨＴＴＰレスポンスと共にSet-Cookieヘッダを受信したユーザ端末３００のブラウザ３００ａは、Set-Cookieヘッダにて示された有効範囲に対するクッキーを設定する。しかしながらユーザ端末３００のブラウザ３００ａから見ると、リバースプロキシ１００を介してＨＴＴＰレスポンスを受信する場合には、このＨＴＴＰリクエストの送信元はウェブサーバ２００ではなくリバースプロキシ１００である。一般的に、ウェブサーバ２００が返すSet-Cookieヘッダ内のドメインパラメータ、パスパラメータの値は、リバースプロキシ１００上でのドメインパラメータ、パスパラメータの値としては正しくないため、このSet-Cookieヘッダを受け取ったブラウザ３００ａは、このSet-Cookieヘッダを無視するか、または正しくない範囲に対してクッキーを送り返すことになる。
【００２２】
そこで本実施の形態では、リバースプロキシ１００を介してウェブサーバ２００からユーザ端末３００のブラウザ３００ａへレスポンスを返送する場合であっても、ブラウザ３００ａにSet-Cookieヘッダを透過的に扱うための変形を行う。 Set-Cookieヘッダの変形方法として本実施の形態では、このSet-Cookieヘッダに含まれるドメインパラメータ（ドメインに関する情報）を削除して、このドメインに関する情報をパスパラメータ（パスに関する情報）に埋め込む。この際、このSet-Cookieヘッダによって設定されるクッキーの有効範囲を階層的に絞り込むために、ドメインに関する情報を構成する構成要素を逆順に並べ替える。例えば、“www.abc.com”の構成要素の並び順を“com.abc.www”とする。さらにこの構成要素を区切る区切り文字“.”を“/”として置換したものをパスに関する情報に埋め込む。
以下、本実施の形態では、ＦＱＤＮ（Full Qualified Domain Name）が上述のようにして加工されたものを「リバースドＦＱＤＮ」（Reversed Full Qualified Domain Name）と称する。
【００２３】
以上のように本実施の形態では、Set-Cookieヘッダに含まれるドメイン情報を削除し、このドメイン情報に対してリバースドＦＱＤＮと同様の操作をしたものをパスに関する情報に埋め込んでSet-Cookieヘッダを書き換える。このようにしてSet-Cookieヘッダを書き換えれば、ブラウザ３００ａにおいて受信されるSet-Cookieヘッダ内にドメインパラメータが存在しないので、リバースプロキシ１００から送信されたSet-Cookieヘッダであっても無視されることはない。そして、次回以降にクッキーの有効範囲に対してＨＴＴＰリクエストを送信する際には、このＨＴＴＰリクエストに当該クッキーを埋め込んで送信する。
【００２４】
図２は、本実施の形態におけるリバースプロキシ１００の機能を示すブロック図である。以下、図２に例示する各機能は、リバースプロキシ１００のプログラム制御されたＣＰＵにて実現されるソフトウェアブロックである。
図２に示すように、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスを中継するリバースプロキシ１００は、ＨＴＴＰリクエストを送信するウェブサーバ２００を特定するウェブサーバ名取得部１１０と、ＨＴＴＰリクエストの送信先のＵＲＬを書き換えるＵＲＬ書き換え部１２０と、ＨＴＴＰリクエストをこのウェブサーバ２００に転送するＨＴＴＰリクエスト転送部１３０とを備える。上記のウェブサーバ名取得部１１０と、ＵＲＬ書き換え部１２０と、ＨＴＴＰリクエスト転送部１３０とで、ＨＴＴＰリクエストをウェブサーバ２００に転送するＨＴＴＰリクエスト転送手段を構成する。
本実施の形態では、ユーザ端末３００から送信され、リクエスト転送手段により転送されるＨＴＴＰリクエストは、
http://<reverse proxy>/<prefix>/<path name of Web server>
となり、必ずリバースプロキシ１００を経由してウェブサーバ２００に転送されるものとする。
【００２５】
また、本実施の形態におけるリバースプロキシ１００は、ウェブサーバ２００から返送されたＨＴＴＰレスポンスに含まれるSet-Cookieヘッダを所定の形式に書き換えるSet-Cookieヘッダ書き換え部１４０と、このＨＴＴＰレスポンスに含まれるリンクやロケーションヘッダ等を書き換えるリンク・ロケーションヘッダ書き換え部１５０と、Set-Cookieヘッダ書き換え部１４０及びリンク・ロケーションヘッダ書き換え部１５０によって書き換えられたＨＴＴＰレスポンスを返送先のユーザ端末３００に送信するＨＴＴＰレスポンス送信部１６０とをさらに備える。上記のSet-Cookieヘッダ書き換え部１４０と、リンク・ロケーションヘッダ書き換え部１５０と、ＨＴＴＰレスポンス送信部１６０とで、ＨＴＴＰレスポンスをユーザ端末３００に転送するＨＴＴＰレスポンス転送手段を構成する。
【００２６】
ウェブサーバ名取得部１１０は、ＨＴＴＰリクエストに基づいてprefixの記述からこのＨＴＴＰリクエストを送信するウェブサーバ２００を特定する。但し、後述のように本実施の形態では、ＨＴＴＰリクエストのprefix部分に、リバースドＦＱＤＮで記述されたウェブサーバのドメインに関する情報が入るので、このリバースドＦＱＤＮより直接ウェブサーバ名を取得する。そしてウェブサーバ名取得部１１０は、ＨＴＴＰリクエストの送信先のウェブサーバ名を保持すると共に、このＨＴＴＰリクエストをＵＲＬ書き換え部１２０に送る。
【００２７】
ＵＲＬ書き換え部１２０は、ウェブサーバ２００においてＨＴＴＰリクエストを送信するパスを特定するためにＨＴＴＰリクエストの送信先のＵＲＬを書き換える。このＵＲＬ書き換え部１２０は、送信されたＨＴＴＰリクエストからprefixを削除して、このＨＴＴＰリクエストの送信先となるウェブサーバ２００における本来のＵＲＬを記述する。すなわちＵＲＬ書き換え部１２０は、ＨＴＴＰリクエストにおけるリバースドＦＱＤＮのドメインに関する情報を並べ替えると共に、このドメインに関する情報の構成要素を区切る文字列（“/”）を所定の文字列（“．”）に置換する。例えばＨＴＴＰリクエスト内に、ドメインに関する情報として“com/abc/www”（リバースドＦＱＤＮ）が存在していた場合には、このドメインに関する情報をウェブサーバ２００における本来のドメイン“www.abc.com”に書き換える。そして、このドメインにパスに関する情報を加えることにより、このＨＴＴＰリクエストの送信先となるウェブサーバ２００のＵＲＬ、例えば“http://www.abc.com/path1/index.html”が生成される。そしてＵＲＬ書き換え部１２０は、このＨＴＴＰリクエストをＨＴＴＰリクエスト転送部１３０に送る。
【００２８】
ＨＴＴＰリクエスト転送部１３０は、ウェブサーバ名取得部１１０によって送信先のウェブサーバ名が特定され、ＵＲＬ書き換え部１２０によって送信先のＵＲＬが書き換えられたＨＴＴＰリクエスト（２）を、当該特定されたウェブサーバ２００の所定のＵＲＬに転送する。
【００２９】
リバースプロキシ１００によって転送されたＨＴＴＰリクエストを受信したウェブサーバ２００は、このＨＴＴＰリクエストに基づいたＨＴＴＰレスポンスを、当該ＨＴＴＰリクエストを送信したユーザ端末３００に返送する。そして、このＨＴＴＰレスポンスは、リバースプロキシ１００によって中継される。
Set-Cookieヘッダ書き換え部１４０は、ウェブサーバ２００から返送されたＨＴＴＰレスポンスに含まれるSet-Cookieヘッダの書き換えを行う。このSet-Cookieヘッダ書き換え部１４０においてクッキーを書き換えるための変換規則については、図３に示す例を用いて説明する。
【００３０】
図３は、Set-Cookieヘッダ書き換え部１４０におけるSet−Cookieヘッダの書き換え規則を示す図である。図３では、Set-Cookieヘッダに含まれるドメインパラメータを削除し、パスパラメータを変換する際の変換規則を示す。ここでは、Set-Cookieヘッダに含まれるパラメータを、ケース１〜ケース４の４つの場合に分けて、それぞれの場合においてどのように変換するかについて説明する。以下に示す変換規則の例では、図２に示したウェブサーバ２００から返送されるＨＴＴＰレスポンス（３）に含まれるSet-CookieヘッダをSet-Cookieヘッダ（３）、本実施の形態における変換規則にしたがってSet−Cookieヘッダ書き換え部１４０において書き換えられたＨＴＴＰレスポンスに含まれるSet-CookieヘッダをSet-Cookieヘッダ（４）と示す。
【００３１】
ケース１： domain=<Web Server name>；path=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のＦＱＤＮがパラメータの値で、且つ、このウェブサーバ２００のパスが“/”（ルートディレクトリ）である場合には、ウェブサーバ２００からは
（３）Set-Cookie：name1=value1；domain=www.abc.com；path=/
というSet-Cookieヘッダが返送される。このSet-Cookieヘッダは、リバースプロキシ１００のSet-Cookieヘッダ書き換え部１４０において
（４）Set-Cookie：name1=value1；path=/com/abc/www/_/
と変換される。
このようにケース１に示す変換規則では、Set-Cookieヘッダのドメインパラメータ“domain=www.abc.com”が削除される。そして、このドメインパラメータの構成要素を逆順に並べ替えて、当該構成要素の区切り文字を“/”に置換して生成したリバースドＦＱＤＮ“com/abc/www”をパスパラメータに埋め込む。さらに、パスパラメータにおいてウェブサーバ２００のドメインを示す部分とウェブサーバ２００における元々のパスを示す部分との境界部分には、区切り文字として“_”が挿入される。以上のようにしてSet-Cookieヘッダが変換されて、新たなパスパラメータが生成される。ここでは、パスパラメータにおける区切り文字として“_”を用いているが、ホスト名に使用することができず、ＵＲＬの指定に用いることができる文字であれば特に問題はない。
【００３２】
ケース２：domain=<domain name of Web Server>；path=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のドメインがドメインパラメータの値（例えば“www”を除いた“abc.com”）であり、且つ、パスが“/”である場合には、ウェブサーバ２００からは
（３）Set-Cookie：name1=value1；domain=abc.com；path=/
というSet-Cookieヘッダが返送され、Set-Cookieヘッダ書き換え部１４０において
（４）Set-Cookie：name1=value1；path=/com/abc/
と変換される。つまり、ケース２に示す変換規則では、Set-Cookieヘッダのドメインパラメータ“domain=abc.com”が削除される。そして、この構成要素が逆順に並べ替えられ、且つ、この構成要素の区切り文字を置換して生成された“com/abc”がパスパラメータに埋め込まれてSet-Cookieヘッダが生成される。
【００３３】
ケース３：domain=<Web Server name>；path!=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のＦＱＤＮがドメインパラメータの値であり、且つ、パスが“/”でない場合には、ウェブサーバ２００からは
（３）Set-Cookie：name1=value1；domain=www.abc.com；path=/path1/
というSet-Cookieヘッダが返送され、Set-Cookieヘッダ書き換え部１４０において
（４）Set-Cookie：name1=value1；path=/com/abc/www/_/path1/
と変換される。つまり、ケース３に示す変換規則では、Set-Cookieヘッダのドメインパラメータ“domain=www.abc.com”が削除される。そして、この構成要素が逆順に並べ替えられ、且つ、この構成要素の区切り文字を置換して生成された“com/abc/www”と元のパスパラメータの値“/path1/”とから、新しいパスパラメータの値“/com/abc/www/_/path1/”が生成される。
【００３４】
ケース４：domain=<domain name of Web Server >；path!=/
すなわち、Set-Cookieヘッダを返送するウェブサーバ２００のドメインがドメインパラメータの値であり、且つ、パスが“/”でない場合である。この場合は本実施の形態ではサポートできない。しかしながらこのケースは、複数のウェブサーバ２００に同じパスが存在していることを意味し、殆ど有り得ないケースである。
【００３５】
また、リンク・ロケーションヘッダ書き換え部１５０では、このＨＴＴＰレスポンス内のリンク及びロケーションヘッダの内容を書き換える。すなわち、ＨＴＴＰリクエストに応じて発生するＨＴＴＰレスポンスがリバースプロキシ１００を経由していることを示す内容となるように、このＨＴＴＰレスポンス内のリンク及びロケーションヘッダの内容を書き換える（<RFQDN>とはリバースドＦＱＤＮのことである）。
http://<reverse proxy>/<RFQDN>/_/…
そして、Set-Cookieヘッダ書き換え部１４０及びリンク・ロケーションヘッダ書き換え部１５０において書き換えられたＨＴＴＰレスポンスをＨＴＴＰレスポンス送信部１６０に送る。このリンク・ロケーションヘッダ書き換え部１５０において書き換えられるＨＴＴＰレスポンスのデータについては、後に図８〜図１０を参照して具体的に説明する。
ＨＴＴＰレスポンス送信部１６０は、リバースドＦＱＤＮに書き換えられたSet-Cookieヘッダを含むＨＴＴＰレスポンス（４）を、ＨＴＴＰリクエストを行ったユーザ端末３００のブラウザ３００ａに送信する。
【００３６】
このようにしてＨＴＴＰレスポンスがユーザ端末３００のブラウザ３００ａにおいて受信されると、ブラウザ３００ａはＨＴＴＰリクエストにて要求されたコンテンツをウィンドウに表示する。また、ブラウザ３００ａには、ＨＴＴＰレスポンスに含まれるSet-Cookieヘッダにしたがってクッキーが設定される。
そして、次回以降、このクッキーの有効範囲のＨＴＴＰリクエストを送信する際には、このＨＴＴＰリクエストのリクエストヘッダにクッキーを埋め込んで送信する。次回以降にリクエストヘッダにクッキーが埋め込まれたＨＴＴＰリクエストを送信する例については、以下に示す図６を用いて説明する。
【００３７】
図４は、本実施の形態のネットワークシステムにおけるデータの流れを示す図である。
図４に示すように、このネットワークシステムは、例えば、ウェブサーバ２０１（ホスト名：“www.abc.com”）、ウェブサーバ２０２（ホスト名：“www2.abc.com”）、ウェブサーバ２０３（ホスト名：“www3.sub.abc.com”）、ウェブサーバ２０４（ホスト名：“www.xyz.com”）の複数のウェブサーバ２００と、リバースプロキシ１００（ホスト名：“rproxy.ijk.com”）と、ユーザ端末３００とから構成されるものとする。
【００３８】
図４に示すネットワークシステムにおいて、ユーザ端末３００からリバースプロキシ１００を介して行われたＨＴＴＰリクエストに対するＨＴＴＰレスポンスに含まれるSet-Cookieヘッダについて説明する。
このとき、ウェブサーバ２０１（“www.abc.com”）からは、ユーザ端末３００に対してクッキーを設定するための、以下の２つのSet−Cookieヘッダ
（Ａ１）Set-Cookie：name1=value1；domain=www.abc.com；path=/；
Set-Cookie：name2=value2；domain= abc.com；path=/；
を含むＨＴＴＰレスポンスが返送されるものとする。
また、ウェブサーバ２０３（“www3.sub.abc.com”）からは、ユーザ端末３００に対してクッキーを設定するための、以下のSet−Cookieヘッダ
（Ｃ１）Set-Cookie：name3=value3；domain=sub.abc.com；path=/；
を含むＨＴＴＰレスポンスが返送されるものとする。
【００３９】
上記の（Ａ１），（Ｃ１）で示した場合におけるクッキー“name1”,“name2”,“name3”それぞれの有効範囲となるウェブサーバ２００を図５に示す。図５に示すように、“name1”によるクッキーの有効範囲には、ウェブサーバ２０１（“www.abc.com”）が含まれる。また、“name2”によるクッキーの有効範囲には、ウェブサーバ２０１（“www.abc.com”）、ウェブサーバ２０２（“www2.abc.com”）、及びウェブサーバ２０３（“www3.sub.abc.com”）が含まれる。さらに、“name3”によるクッキーの有効範囲には、ウェブサーバ２０３（“www3.sub.abc.com”）が含まれる。
【００４０】
ところで、これら（Ａ１），（Ｃ１）に示したSet-Cookieヘッダは、リバースプロキシ１００のSet-Cookieヘッダ書き換え部１４０によって以下のように変換される。
すなわちSet-Cookieヘッダ
（Ａ１）Set-Cookie：name1=value1；domain=www.abc.com；path=/；
は、上記のケース１の変換規則により、
（Ａ２）Set-Cookie：name1=value1；path=/com/abc/www/_/；
となる。
また、Set-Cookieヘッダ
（Ａ１）Set-Cookie：name2=value2；domain= abc.com；path=/；
は、上記のケース２の変換規則により、
（Ａ２）Set-Cookie：name2=value2；path=/com/abc/；
となる。
さらに、Set-Cookieヘッダ
（Ｃ１）Set-Cookie：name1=value1；domain=www.abc.com；path=/；
は、上記のケース２の変換規則により、
（Ｃ２）Set-Cookie：name3=value3；path=/com/abc/sub/；
となる。
【００４１】
よって、その後のユーザ端末３００から各ウェブサーバにアクセスする際、ＨＴＴＰリクエストには、それぞれ図６に示すようなクッキーが埋め込まれる。
すなわち、ユーザ端末３００からウェブサーバ２０１へのＨＴＴＰリクエスト（Ａ３）のリクエストヘッダには、図５に示したクッキーの有効範囲に対応するクッキーが埋め込まれ
http://rproxy.ijk.com/com/abc/www/_/…
Cookie：name1=value1；name2=value2；
として送信される。
また、ユーザ端末３００からウェブサーバ２０２へのＨＴＴＰリクエスト（Ｂ３）のリクエストヘッダには、図５に示したクッキーの有効範囲に対応するクッキーが埋め込まれ
http://rproxy.ijk.com/com/abc/www2/_/…
Cookie：name2=value2；
として送信される。
さらに、ユーザ端末３００からウェブサーバ２０３へのＨＴＴＰリクエスト（Ｃ３）のリクエストヘッダには、図５に示したクッキーの有効範囲に対応するクッキーが埋め込まれ
http://rproxy.ijk.com/com/abc/sub/www3/_/…
Cookie：name2=value2；name3=value3；
として送信される。
またさらに、ユーザ端末３００からウェブサーバ２０４へのＨＴＴＰリクエスト（Ｄ３）のリクエストヘッダは
http://rproxy.ijk.com/com/xyz/www/_/…
として送信されるが、このＨＴＴＰリクエスト（Ｄ３）に対応するクッキーは存在しないのでリクエストヘッダにクッキーは埋め込まれない。
以上のように、図６に示した２回目以降に送信されるＨＴＴＰリクエストに含まれるクッキーは、図５に示したクッキーの有効範囲となるウェブサーバ２００に一致している。換言すれば、リバースプロキシ１００を介してクッキーが透過的に扱われているといえる。
【００４２】
これら（Ａ３）〜（Ｃ３）のＨＴＴＰリクエストは、リバースプロキシ１００のウェブサーバ名取得部１１０及びＵＲＬ書き換え部１２０において所定の処理を経て（Ａ４）〜（Ｃ４）に変換される。そしてＨＴＴＰリクエスト転送部１３０によって、ＨＴＴＰリクエスト（Ａ４）はウェブサーバ２０１に、ＨＴＴＰリクエスト（Ｂ４）はウェブサーバ２０２に、ＨＴＴＰリクエスト（Ｃ４）はウェブサーバ２０３にそれぞれ転送される。
また同様にして、ＨＴＴＰリクエスト転送部１３０によって、（Ｄ３）のＨＴＴＰリクエストは（Ｄ４）としてウェブサーバ２０４に転送される。
【００４３】
ところで、通常のＨＴＴＰリクエストにおいて使用されるポート番号は８０番であるが、本実施の形態では、ＨＴＴＰリクエストを送信する送信先のウェブサーバ２００のポート番号がデフォルトのポート番号ではなく、明示的に指定する必要がある場合は、例えば以下のようにポート番号を指定すればよい。
http://<reverse proxy>/<RFQDN>/_<port>/<path name of Web server>
このようにして“<port>”部分にウェブサーバ２００のポート番号を指定しておけば、ウェブサーバ２００において通常とは異なるポートがＨＴＴＰリクエスト用のポートとして用いられている場合であっても、ＨＴＴＰリクエストを当該ウェブサーバ２００に送信することができる。
【００４４】
本実施の形態では、<prefix>として“<RFQDN>_”を用いているが、<RFQDN>の前に固定の文字列、例えば“xxx/”が付いていてもクッキーを透過的に扱うことができる。つまり、ブラウザ３００ａがリバースプロキシ１００を経由してウェブサーバ２０１（“www.abc.com”）の“/index.html”にアクセスする場合は、以下のようになる。
http://<reverse proxy>/xxx/com/abc/www/_/index.html
そして、ウェブサーバ２０１が以下のようなSet-Cookieヘッダを返した場合、
Set-Cookie：name1=value1；domain=abc.com；path=/；
リバースプロキシ１００は、このSet-Cookieヘッダを以下のように変換してユーザ端末３００に送る。
Set-Cookie：name1=value1；path=/xxx/com/abc/；
【００４５】
本実施の形態では、“www.abc.com”を変換することにより、“com/abc/www”とした。しかし、ドメインパラメータを指定する場合において、“.com”や“.net”、又は“.co.jp”といったトップレベルドメインだけの指定を行うことはできず、常に１つ下の階層（サブドメイン）からでなければ、このドメインパラメータの指定を行うことができない。つまりドメインパラメータの指定は、“abc.com”や“abc.net”、又は“abc.co.jp”というように、１つ下の階層から行わなければならない。よって、リバースプロキシ１００へのアクセスパスは、最低限指定すべきドメインを１つにまとめて、以下のようにしても良い。
（図４、Ａ３）http://<reverse proxy>/abc-com/www/_/index.html
（図４、Ｃ３）http://<reverse proxy>/abc-com/sub/www3/_/index.html
これらのＨＴＴＰリクエストを受け取ったリバースプロキシ１００は、区切り文字“_”の前までの文字列から転送先のウェブサーバ名をそれぞれ、“www.abc.com”、“www3.sub.abc.com”と判断し、それぞれのウェブサーバ２００に対して以下のＨＴＴＰリクエストを送る。
（図４、Ａ４）http://www.abc.com/index.html
（図４、Ｃ４）http://www3.sub.abc.com/index.html
また、これらのウェブサーバ２００が以下のようなSet-Cookieヘッダを返したとする。
（図４、Ａ１）Set-Cookie：id1=001；domain=www.abc.com；path=/；
（図４、Ｃ１）Set-Cookie：id1=001；domain=sub.abc.com；path=/；
リバースプロキシ１００は、このSet-Cookieヘッダを以下のように変換する。
（図４、Ａ２）Set-Cookie：id1=001；path=/abc-com/www/_/；
（図４、Ｃ２）Set-Cookie：id1=001；path=/abc-com/sub/；
このような<prefix>を用いてもクッキーを透過的に扱うことができる。
【００４６】
また、図４を用いて説明した例では、リバースプロキシ１００が返すSet-Cookieヘッダ内でドメインパラメータを指定していないが、このような場合Set-Cookieヘッダは、ＨＴＴＰレスポンスを送信したサーバを示す。そこで図４に示した例において、例えば
Set-Cookie：name1=value1；path=/com/abc/www/_/；domain=<reverse proxy>といったように、Set-Cookieヘッダのドメインパラメータを自装置のサーバ名に置換して、このリバースプロキシ１００のサーバ名を明示的に指定しても良い。
【００４７】
図７は、本実施の形態のリバースプロキシ１００における処理を示すフローチャートである。図７に示すフローチャートでは、リバースプロキシ１００において、ユーザ端末３００から送信されたＨＴＴＰリクエスト、及びウェブサーバ２００から返送されたＨＴＴＰレスポンスに対して行われる処理について説明する。また、以下に示す各処理において用いられるデータ（ＨＴＴＰレスポンス）を図８〜図１０に示す。
ユーザ端末３００からクッキーが埋め込まれたＨＴＴＰリクエストが送信されると、このＨＴＴＰリクエストは、リバースプロキシ１００によって受信され、ウェブサーバ名取得部１１０に渡される（ステップ７０１）。以下では、ステップ７０１において受信されたＨＴＴＰリクエストが
（Ｒｅｑ１）GET /com/abc/www/_/index.html HTTP/1.1
であるものとして説明する。
【００４８】
ステップ７０１において受信されたＨＴＴＰリクエストからは、ウェブサーバ名取得部１１０によって、prefixに基づいてウェブサーバ名が取得される（ステップ７０２）。これにより、このＨＴＴＰリクエストの送信先のウェブサーバ２００が特定される。ステップ７０２においてＨＴＴＰリクエストの送信先のウェブサーバ名が特定されたＨＴＴＰリクエストは、ＵＲＬ書き換え部１２０に送信される。ＵＲＬ書き換え部１２０では、ステップ７０２においてウェブサーバ名取得部１１０において特定された情報に基づいてＵＲＬの書き換えを行う（ステップ７０３）。すなわちステップ７０３においてＵＲＬ書き換え部１２０は、ＨＴＴＰリクエストの送信先となるウェブサーバ２００における本来のＵＲＬとパス“/www.abc.com/index.html”を取得する。ＨＴＴＰリクエストの送信先のウェブサーバ２００（“www.abc.com”）、及びこのウェブサーバ２００内におけるＵＲＬ（“www.abc.com”のルートディレクトリの“index.html”）を特定されたＨＴＴＰリクエスト
（Ｒｅｑ２）GET /index.html HTTP/1.1
は、ＨＴＴＰリクエスト転送部１３０に送信される。そしてこのＨＴＴＰリクエストは、ＨＴＴＰリクエスト転送部１３０によって、ステップ７０２で特定されたウェブサーバ２００に転送される（ステップ７０４）。
【００４９】
ＨＴＴＰリクエストを受け取ったウェブサーバ２００は、リバースプロキシ１００から転送されたＨＴＴＰリクエストに応じたＨＴＴＰレスポンスが、ＨＴＴＰリクエストを行ったユーザ端末３００に対して送信される。このＨＴＴＰレスポンスには、後々行われるＨＴＴＰリクエストにおいてユーザの状態を通知するためのCookieヘッダが埋め込まれて返送される。ウェブサーバ２００から返送されたＨＴＴＰレスポンスは、一旦リバースプロキシ１００を中継してユーザ端末３００に返送される。すなわち、ウェブサーバ２００から返送されたＨＴＴＰレスポンスは、リバースプロキシ１００によって受信され、Set-Cookieヘッダ書き換え部１４０に渡される（ステップ７０５）。
【００５０】
ステップ７０５において受信されるＨＴＴＰレスポンスの一例を図８に示す。図８に示すように、このＨＴＴＰレスポンスにはSet-Cookieヘッダ
Set-Cookie：sessionid=001；path=/；domain=abc.com；
が含まれている。そしてこのSet-Cookieヘッダには、ユーザを特定するｉｄに相当する“sessionid=001”と、このSet-Cookieヘッダによって設定されたクッキーをブラウザ３００ａが送り返す返送先のウェブサーバ２００のＵＲＬ（パス）を特定する“path=/”と、返送先のウェブサーバのドメインを特定する“domain=abc.com”とが含まれる。また、このＨＴＴＰレスポンスは、Set-Cookieヘッダの他にもウェブサーバ２００から返送される種々のヘッダ情報を含む。
【００５１】
リバースプロキシ１００においてＨＴＴＰレスポンスが受信されたら、Set-Cookieヘッダ書き換え部１４０では、ＨＴＴＰレスポンス内にSet-Cookieヘッダが存在しているか否かの判断が行われる（ステップ７０６）。ステップ７０６において、ＨＴＴＰレスポンス内にSet-Cookieヘッダが存在していると判断された場合には、Set-Cookieヘッダ書き換え部１４０においてSet-Cookieヘッダの書き換えが行われる（ステップ７０７）。ステップ７０７におけるSet-Cookieヘッダの書き換えは、図３に示した変換規則にしたがって行われる。すなわち、ドメインパラメータを削除し、このドメインを構成する構成要素を逆順に並べ替え、さらにこの構成要素を区切る区切り文字“.”を“/”として置換したものを当該Set-Cookieヘッダのパスパラメータに埋め込む。ステップ７０６において、ＨＴＴＰレスポンス内にSet-Cookieヘッダが存在していないと判断された場合には、ステップ７０７の処理は省略される。
【００５２】
ステップ７０７においてSet-Cookieヘッダが書き換えられたＨＴＴＰレスポンスの一例を図９に示す。図９に示すように、ステップ７０７において書き換えられたSet-Cookieヘッダは
Set-Cookie：sessionid=001；path=/com/abc/;
となる。上記のSet-Cookieヘッダは、図３に示した変換規則にしたがって書き換えられていることがわかる。
【００５３】
ステップ７０７においてSet-CookieヘッダがリバースドＦＱＤＮに書き換えられたＨＴＴＰレスポンスは、Set-Cookieヘッダ書き換え部１４０からリンク・ロケーションヘッダ書き換え部１５０に送信される。そして、このＨＴＴＰリクエストを受信したリンク・ロケーションヘッダ書き換え部１５０では、コンテンツ内のリンク及びロケーションヘッダの書き換えを行う（ステップ７０８）。
【００５４】
ステップ７０８において、リンクが書き換えられた状態のＨＴＴＰレスポンスの一例を図１０に示す。ステップ７０８において書き換えられたリンク先の指定部分は、図８及び図９に示した
“/menu1.html”
“/menu2.html”
“/menu3.html”
から、図１０に示す
“/com/abc/www/_/menu1.html”
“/com/abc/www/_/menu2.html”
“/com/abc/www/_/menu3.html”
といったように、リバースドＦＱＤＮが付与された絶対パスに書き換えられる。
【００５５】
以上のようにして書き換えられたブラウザが認識可能な形式のSet-Cookieヘッダを含むＨＴＴＰレスポンスは、ＨＴＴＰレスポンス送信部１６０によりステップ７０１において受信されたＨＴＴＰリクエストを送信したユーザ端末３００に対して送信される（ステップ７０９）。そして、ユーザ端末３００のブラウザには、このＨＴＴＰレスポンス及びこのＨＴＴＰレスポンスとリンクしたデータやファイルに基づいたコンテンツが表示され、ＨＴＴＰレスポンスに含まれるSet-Cookieヘッダに基づいて、所定の有効範囲に対するクッキーがブラウザに保持される。
【００５６】
以上のように本実施の形態におけるリバースプロキシ１００は、ドメインパラメータを削除し、パスパラメータを書き換えた Set-Cookieヘッダをユーザ端末３００に送信する。そうすることによりユーザ端末３００のブラウザ３００ａには、リバースプロキシ１００を介して返送されたＨＴＴＰレスポンスに含まれるSet-Cookieヘッダに基づいてクッキーが設定され、保持される。
そして次回以降、ブラウザ３００ａが送信するＨＴＴＰリクエストにCookieヘッダが付いている場合、リバースプロキシ１００は、このCookieヘッダをそのまま対応するウェブサーバ２００に転送すれば、そのCookieはウェブサーバ２００がSet-Cookieヘッダ内で指定したドメイン、パスに合致している範囲にのみ送られることになる。
【００５７】
【発明の効果】
以上説明したように、本発明によれば、リバースプロキシを経由してサーバへアクセスするネットワークシステムにおいて、サーバによって設定されたクッキーを透過的に扱うようにすることができる。
【００５８】
また、本発明によれば、サーバの設定したクッキーを透過的に扱うためにSet-Cookieを書き換える機能を備えたリバースプロキシを提供することができる。
【図面の簡単な説明】
【図１】 本実施の形態におけるネットワークシステムの構成を示す図である。
【図２】 本実施の形態におけるリバースプロキシの機能を示すブロック図である。
【図３】 本実施の形態におけるSet-Cookieヘッダ書き換え部におけるクッキーの変換規則を示す図である。
【図４】 本実施の形態のネットワークシステムにおけるデータの流れを示す図である。
【図５】 本実施の形態の変換規則におけるクッキーの有効範囲となるウェブサーバの一例を示す図である。
【図６】 各ケースに対応したリバースドＦＱＤＮのSet-Cookieヘッダの一例を示す図である。
【図７】 本実施の形態のリバースプロキシにおける処理を示すフローチャートである。
【図８】 本実施の形態のリバースプロキシにおいて受信されるレスポンスデータの一例を示す図である。
【図９】 本実施のリバースプロキシにおいてSet-Cookieヘッダが書き換えられたレスポンスデータの一例を示す図である。
【図１０】 本実施の形態のリバースプロキシから送信されるレスポンスデータの一例を示す図である。
【図１１】 ウェブサーバから送信されるSet-Cookieヘッダによって決められるクッキーの有効範囲と、このクッキーの有効範囲であるウェブサーバに送信されるＨＴＴＰリクエスト及びクッキーの一例を示す図である。
【図１２】 リバースプロキシにおいて管理されるテーブルを示す図である。
【符号の説明】
１００…リバースプロキシ、１１０…ウェブサーバ名取得部、１２０…ＵＲＬ書き換え部、１３０…ＨＴＴＰリクエスト転送部、１４０…Set-Cookieヘッダ書き換え部、１５０…リンク・ロケーションヘッダ書き換え部、１６０…ＨＴＴＰレスポンス送信部、２００…ウェブサーバ、３００…ユーザ端末、４００…ネットワーク、５００…ネットワーク
Claims (12)
- ネットワーク上に設けられた複数のウェブサーバと、当該複数のウェブサーバに対する外部からのアクセスを中継するリバースプロキシとを備えたネットワークシステムであって、
前記ウェブサーバは、
前記ネットワークに接続された所定の端末から送信されたリクエストに応じて当該端末の状態を保持するための情報を含むレスポンスを当該端末に返送し、
前記リバースプロキシは、
前記レスポンスに含まれる前記端末の状態を保持するための前記情報に含まれる前記ウェブサーバのドメインを指定するドメインパラメータを削除し、前記ドメインパラメータを構成する構成要素の並び順を逆順に並べ替え、当該情報に含まれる当該ウェブサーバにおけるパスパラメータに埋め込み、当該端末に返送し、
前記端末から前記ウェブサーバへ送信されたリクエストを受信し、当該リクエストのアクセス先であるウェブサーバを特定し、当該リクエストに記述されているアクセスパスを前記ウェブサーバにおける本来のパスに書き換え、当該リクエストを当該ウェブサーバに転送することを特徴とするネットワークシステム。 - ウェブサーバからユーザ端末へのデータの送信を中継するリバースプロキシであって、
前記ウェブサーバから前記ユーザ端末に返送された前記データを受信すると共に、当該データに含まれるドメインの記述を逆順に並べ替えパスパラメータに埋め込んで、当該データのヘッダを書き換えるヘッダ書き換え部と、
前記ヘッダ書き換え部によって書き換えられた前記データを前記ユーザ端末に送信するデータ送信部と
を備えることを特徴とするリバースプロキシ。 - 前記データに含まれるリンク及びロケーションのドメイン及びパスを前記ヘッダ書き換え部によって書き換えられた前記ドメインの記述を含むパスに合わせて書き換えるリンク・ロケーション書き換え部をさらに備えたことを特徴とする請求項２に記載のリバースプロキシ。
- 前記ユーザ端末から前記ウェブサーバへ送信されたリクエストを受信し、当該リクエストに基づいてネットワーク上に配置された複数のサーバのうち当該リクエストのアクセス先である前記ウェブサーバを特定するウェブサーバ名取得部と、
前記リクエストに基づいて当該リクエストに記述されているアクセスパスを前記ウェブサーバにおける本来のパスに書き換えるＵＲＬ書き換え部と、
前記リクエストを当該リクエストによって示される前記ウェブサーバに転送するリクエスト転送部と
をさらに備えたことを特徴とする請求項２に記載のリバースプロキシ。 - 端末とサーバとの間におけるＨＴＴＰリクエストの送信及びＨＴＴＰレスポンスの返送を中継するコンピュータ装置であって、
前記端末のブラウザから送信されたクッキーと前記ＨＴＴＰリクエストとを中継して当該ＨＴＴＰリクエストの送信先の前記サーバに転送するＨＴＴＰリクエスト転送手段と、
前記ＨＴＴＰリクエストに応じて前記サーバから返送されたＨＴＴＰレスポンスを受信し、セットクッキーヘッダに記述されたドメインを削除して当該ドメインを構成する構成要素の並び順を逆順に並べ替えて当該セットクッキーヘッダに記述されたパスに埋め込んで前記端末に転送するＨＴＴＰレスポンス転送手段と
を備えたことを特徴とするコンピュータ装置。 - 前記ＨＴＴＰリクエスト転送手段は、
前記サーバのドメインと共に当該サーバの通信ポートのポート番号を指定して前記ＨＴＴＰリクエストを前記サーバに転送することを特徴とする請求項５に記載のコンピュータ装置。 - 前記ＨＴＴＰレスポンス転送手段は、
前記ＨＴＴＰレスポンスに応じて所定の固定文字列を前記セットクッキーヘッダに付け加えて前記端末に転送することを特徴とする請求項５に記載のコンピュータ装置。 - 前記ＨＴＴＰレスポンス転送手段は、
前記ドメインの前記構成要素の並び順を逆順に並べ替える際に、当該ドメインを特定するのに必要な当該構成要素を１つに纏めて前記端末に転送することを特徴とする請求項５に記載のコンピュータ装置。 - 前記ＨＴＴＰレスポンス転送手段は、
前記サーバの前記セットクッキーヘッダ内のドメインパラメータを自装置のサーバ名に置換して前記端末に転送することを特徴とする請求項５に記載のコンピュータ装置。 - 第１のコンピュータ装置と第２のコンピュータ装置とのデータの送受信を中継するコンピュータ装置におけるデータ処理方法であって、
前記第１のコンピュータ装置から前記第２のコンピュータ装置に対して送信されたレスポンスを受信するステップと、
前記レスポンスにセットクッキーヘッダが含まれているか否かを判断するステップと、
前記レスポンスにセットクッキーヘッダが含まれている場合には、前記第２のコンピュータ装置に設定されるクッキーが当該第２のコンピュータ装置において認識可能な形式となるように当該セットクッキーヘッダに含まれるドメインを逆順に並べ替えパスパラメータに埋め込んで当該セットクッキーヘッダを書き換えるステップと、
前記セットクッキーヘッダが書き換えられた前記レスポンスを前記第２のコンピュータ装置に送信するステップと
を含むことを特徴とするデータ処理方法。 - 第１のコンピュータ装置と第２のコンピュータ装置とのデータの送受信を中継するコンピュータ装置を制御して所定のデータ処理を行うプログラムであって、
前記第１のコンピュータ装置から前記第２のコンピュータ装置に対して送信されたレスポンスを受信する処理と、
前記レスポンスにセットクッキーヘッダが含まれている場合には、前記第２のコンピュータ装置に設定されるクッキーが当該第２のコンピュータ装置において認識可能な形式となるように当該セットクッキーヘッダに含まれるドメインを逆順に並べ替えパスパラメータに埋め込んで当該セットクッキーヘッダを書き換える処理と、
前記セットクッキーヘッダが書き換えられた前記レスポンスを前記第２のコンピュータ装置に送信する処理と
を前記コンピュータ装置に実行させることを特徴とするプログラム。 - 前記レスポンスに含まれるリンク及びロケーションのドメイン及びパスを前記セットクッキーヘッダに含まれる前記パスに合わせて書き換える処理を前記コンピュータ装置にさらに実行させることを特徴とする請求項１１に記載のプログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002257969A JP4179535B2 (ja) | 2002-09-03 | 2002-09-03 | ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム |
| CNB031786383A CN100508518C (zh) | 2002-09-03 | 2003-07-18 | 网络***、反向代理装置、计算机设备以及数据处理方法 |
| US10/653,666 US20040044768A1 (en) | 2002-03-09 | 2003-09-02 | Reverse proxy mediator for servers |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002257969A JP4179535B2 (ja) | 2002-09-03 | 2002-09-03 | ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004094805A JP2004094805A (ja) | 2004-03-25 |
| JP4179535B2 true JP4179535B2 (ja) | 2008-11-12 |
Family
ID=31973007
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002257969A Expired - Fee Related JP4179535B2 (ja) | 2002-03-09 | 2002-09-03 | ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20040044768A1 (ja) |
| JP (1) | JP4179535B2 (ja) |
| CN (1) | CN100508518C (ja) |
Families Citing this family (57)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7673329B2 (en) * | 2000-05-26 | 2010-03-02 | Symantec Corporation | Method and apparatus for encrypted communications to a secure server |
| US20060031382A1 (en) * | 2004-06-04 | 2006-02-09 | Arvind Pradhakar | System and method for translating fully qualified domain name access in a browser environment |
| US7333990B1 (en) * | 2004-06-22 | 2008-02-19 | Sun Microsystems, Inc. | Dynamic reverse proxy |
| US7873707B1 (en) | 2004-10-27 | 2011-01-18 | Oracle America, Inc. | Client-side URL rewriter |
| DE102004053513A1 (de) * | 2004-10-29 | 2006-05-04 | Hurra Communications Gmbh | Verfahren und Suchmaschine zum automatischen computergestützten Erstellen einer Suchergebnisliste mit Netzwerk-Seiten eines Client-Server-Netzwerks mit einem bestimmten Inhalt |
| US7610400B2 (en) * | 2004-11-23 | 2009-10-27 | Juniper Networks, Inc. | Rule-based networking device |
| US8312074B2 (en) * | 2005-05-26 | 2012-11-13 | Bytemobile, Inc. | Method for multipart encoding |
| JP4285655B2 (ja) * | 2005-07-19 | 2009-06-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Ｗｅｂサービスを提供する方法、装置、プログラム |
| US8478894B2 (en) * | 2005-07-21 | 2013-07-02 | International Business Machines Corporation | Web application response cloaking |
| FR2892585A1 (fr) * | 2005-10-26 | 2007-04-27 | France Telecom | Procede et systeme de protection d'un lien d'acces a un serveur. |
| JP4701132B2 (ja) * | 2005-12-07 | 2011-06-15 | 株式会社エヌ・ティ・ティ・ドコモ | 通信経路設定システム |
| JP5332117B2 (ja) * | 2007-03-06 | 2013-11-06 | 日本電気株式会社 | Ｗｗｗコンテンツ取得システム及びｗｗｗコンテンツ取得方法 |
| JP2008225573A (ja) * | 2007-03-08 | 2008-09-25 | Terumo Corp | 代理サーバ、代理サーバのためのプログラム及び代理アクセス方法 |
| JP5159261B2 (ja) * | 2007-11-12 | 2013-03-06 | インターナショナル・ビジネス・マシーンズ・コーポレーション | セッションを管理する技術 |
| JP4416035B2 (ja) * | 2007-12-28 | 2010-02-17 | 村田機械株式会社 | 中継サーバ及び中継通信システム |
| CN101984778B (zh) | 2008-01-26 | 2014-08-13 | 思杰***有限公司 | 用于细粒度策略驱动的cookie代理的***和方法 |
| US8117325B1 (en) | 2008-04-29 | 2012-02-14 | Juniper Networks, Inc. | Policy-based cross-domain access control for SSL VPN |
| JP5196479B2 (ja) * | 2008-08-26 | 2013-05-15 | 日本電信電話株式会社 | 統一資源位置指定子の構成方法およびハイパーテキスト転送プロトコルネットワーク |
| CN101753606B (zh) * | 2008-12-03 | 2013-01-09 | 北京天融信科技有限公司 | 一种实现web反向代理的方法 |
| US8892631B2 (en) | 2009-04-09 | 2014-11-18 | International Business Machines Corporation | System and method of optimizing digital media processing in a carrier grade web portal environment |
| CN101902485B (zh) * | 2009-05-27 | 2014-05-14 | 北京启明星辰信息技术股份有限公司 | 一种反向Web代理的链接改写方法 |
| US8543676B2 (en) * | 2009-06-16 | 2013-09-24 | International Business Machines Corporation | Delegated resource use in a content based routing environment |
| JP5397071B2 (ja) * | 2009-07-31 | 2014-01-22 | 富士通株式会社 | 中継装置、中継方法、および中継プログラム |
| JP5552292B2 (ja) * | 2009-10-22 | 2014-07-16 | 日本電信電話株式会社 | 注目フォルダの処理切り替え方法及びユーザ端末及びネットワーク・フォルダ・サーバ及びプログラム及びコンピュータ読み取り可能な記録媒体 |
| US9473592B2 (en) * | 2010-03-02 | 2016-10-18 | Usablenet Inc. | Methods for optimizing a web content proxy server and devices thereof |
| US8321502B2 (en) * | 2010-03-02 | 2012-11-27 | Usablenet Inc. | Method for optimizing a web content proxy server and devices thereof |
| JP5581820B2 (ja) * | 2010-06-04 | 2014-09-03 | 富士通株式会社 | 中継サーバ装置、クッキー制御方法およびクッキー制御プログラム |
| US9021586B2 (en) * | 2010-07-20 | 2015-04-28 | At&T Intellectual Property I, L.P. | Apparatus and methods for preventing cross-site request forgery |
| JP5500020B2 (ja) * | 2010-09-24 | 2014-05-21 | 富士通株式会社 | Ｗｅｂアプリケーション提供方法、中継サーバ装置、Ｗｅｂサーバ装置 |
| US8984616B2 (en) | 2010-12-08 | 2015-03-17 | International Business Machines Corporation | Efficient routing for reverse proxies and content-based routers |
| US20120278487A1 (en) * | 2011-04-27 | 2012-11-01 | Woelfel John Harold | System and method of handling requests in a multi-homed reverse proxy |
| US20120327931A1 (en) * | 2011-06-21 | 2012-12-27 | Alcatel-Lucent Usa Inc. | Gateways integrating name-based networks with host-based networks |
| US9015255B2 (en) * | 2012-02-14 | 2015-04-21 | The Nielsen Company (Us), Llc | Methods and apparatus to identify session users with cookie information |
| CN104333573B (zh) * | 2012-06-29 | 2018-04-17 | 北京奇虎科技有限公司 | 一种大并发量请求的处理方法及处理*** |
| CN102780768B (zh) * | 2012-06-29 | 2014-11-19 | 北京奇虎科技有限公司 | 一种大并发量请求的处理方法及处理*** |
| AU2013204953B2 (en) | 2012-08-30 | 2016-09-08 | The Nielsen Company (Us), Llc | Methods and apparatus to collect distributed user information for media impressions |
| JP6054799B2 (ja) * | 2013-03-29 | 2016-12-27 | Kddi株式会社 | Ｗｅｂコンテンツの配信装置 |
| JP6081847B2 (ja) * | 2013-03-29 | 2017-02-15 | Kddi株式会社 | Ｗｅｂコンテンツの配信装置 |
| CA2848175A1 (en) * | 2013-04-03 | 2014-10-03 | Usablenet Inc. | Methods for optimizing a web content proxy server and devices thereof |
| CN104144155B (zh) * | 2013-05-10 | 2018-01-02 | 百度在线网络技术（北京）有限公司 | 用于长连接的会话处理***和会话处理方法 |
| US10068246B2 (en) | 2013-07-12 | 2018-09-04 | The Nielsen Company (Us), Llc | Methods and apparatus to collect distributed user information for media impressions |
| CN104348877B (zh) * | 2013-08-06 | 2018-09-18 | 腾讯科技（深圳）有限公司 | 一种发送Http请求消息的方法及装置 |
| EP2849110A1 (en) * | 2013-09-13 | 2015-03-18 | Gemalto SA | Server using unpredictable scrambled cookie names |
| CN103634165B (zh) * | 2013-12-05 | 2017-01-18 | 北京奇安信科技有限公司 | 一种基于反向代理实现网络测试的方法、终端设备和*** |
| US9237138B2 (en) | 2013-12-31 | 2016-01-12 | The Nielsen Company (Us), Llc | Methods and apparatus to collect distributed user information for media impressions and search terms |
| US20160063539A1 (en) | 2014-08-29 | 2016-03-03 | The Nielsen Company (Us), Llc | Methods and apparatus to associate transactions with media impressions |
| JP6119709B2 (ja) * | 2014-09-29 | 2017-04-26 | ブラザー工業株式会社 | サービスプロバイダ装置、プログラム及びサービス提供方法 |
| US20160381061A1 (en) * | 2015-06-28 | 2016-12-29 | Check Point Software Technologies Ltd. | Proxy for mitigation of attacks exploiting misconfigured or compromised web servers |
| CN105208100B (zh) * | 2015-08-25 | 2018-11-06 | 联创汽车服务有限公司 | 一种接口数据的处理方法 |
| US20170093917A1 (en) * | 2015-09-30 | 2017-03-30 | Fortinet, Inc. | Centralized management and enforcement of online behavioral tracking policies |
| US10205994B2 (en) | 2015-12-17 | 2019-02-12 | The Nielsen Company (Us), Llc | Methods and apparatus to collect distributed user information for media impressions |
| US10021194B2 (en) * | 2016-08-02 | 2018-07-10 | International Business Machines Corporation | Enforced registry of cookies through a theme template |
| CN106878311B (zh) * | 2017-02-22 | 2019-12-06 | 杭州迪普科技股份有限公司 | Http报文的重写方法及装置 |
| JP6608476B2 (ja) * | 2018-03-29 | 2019-11-20 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 中継装置、中継方法および中継プログラム |
| US10728219B2 (en) * | 2018-04-13 | 2020-07-28 | R3 Ltd. | Enhancing security of communications during execution of protocol flows |
| US10938801B2 (en) * | 2018-09-21 | 2021-03-02 | Microsoft Technology Licensing, Llc | Nonce handler for single sign on authentication in reverse proxy solutions |
| CN112260988B (zh) * | 2020-09-16 | 2021-09-24 | 厦门网宿有限公司 | 一种异常请求处理方法和装置 |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6098093A (en) * | 1998-03-19 | 2000-08-01 | International Business Machines Corp. | Maintaining sessions in a clustered server environment |
| JP3493141B2 (ja) * | 1998-06-12 | 2004-02-03 | 富士通株式会社 | ゲートウェイシステムおよび記録媒体 |
| US6405214B1 (en) * | 1998-12-17 | 2002-06-11 | Hewlett-Packard Company | Method of gathering usage information and transmitting to a primary server and a third party server by a client program |
| US6349336B1 (en) * | 1999-04-26 | 2002-02-19 | Hewlett-Packard Company | Agent/proxy connection control across a firewall |
| US7305473B2 (en) * | 1999-05-28 | 2007-12-04 | The Coca-Cola Company | Provision of transparent proxy services to a user of a client device |
| US7188181B1 (en) * | 1999-06-30 | 2007-03-06 | Sun Microsystems, Inc. | Universal session sharing |
| US7137143B2 (en) * | 2000-08-07 | 2006-11-14 | Ingrian Systems Inc. | Method and system for caching secure web content |
| AUPQ924100A0 (en) * | 2000-08-07 | 2000-08-31 | Sharinga Networks Inc. | A method for controlling data at a client device |
| AU2001296774A1 (en) * | 2000-10-09 | 2002-04-22 | Enic Corporation | Registering and using multilingual domain names |
| US7818435B1 (en) * | 2000-12-14 | 2010-10-19 | Fusionone, Inc. | Reverse proxy mechanism for retrieving electronic content associated with a local network |
| US20030037102A1 (en) * | 2001-08-14 | 2003-02-20 | Philippe Eckert | Message broker |
| US20030074432A1 (en) * | 2001-09-26 | 2003-04-17 | Mazzitelli John Joseph | State data management method and system |
| US20030154306A1 (en) * | 2002-02-11 | 2003-08-14 | Perry Stephen Hastings | System and method to proxy inbound connections to privately addressed hosts |
| US20050262357A1 (en) * | 2004-03-11 | 2005-11-24 | Aep Networks | Network access using reverse proxy |
| US20050273849A1 (en) * | 2004-03-11 | 2005-12-08 | Aep Networks | Network access using secure tunnel |
-
2002
- 2002-09-03 JP JP2002257969A patent/JP4179535B2/ja not_active Expired - Fee Related
-
2003
- 2003-07-18 CN CNB031786383A patent/CN100508518C/zh not_active Expired - Fee Related
- 2003-09-02 US US10/653,666 patent/US20040044768A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CN100508518C (zh) | 2009-07-01 |
| US20040044768A1 (en) | 2004-03-04 |
| JP2004094805A (ja) | 2004-03-25 |
| CN1487711A (zh) | 2004-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4179535B2 (ja) | ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム | |
| US7716282B2 (en) | Proxy server apparatus and method for providing service using the same | |
| EP1886470B1 (en) | Method and system for object prediction | |
| US6976090B2 (en) | Differentiated content and application delivery via internet | |
| US8874783B1 (en) | Method and system for forwarding messages received at a traffic manager | |
| US7904073B2 (en) | System and method for processing extensible markup language (XML) documents | |
| JP3807961B2 (ja) | セッション管理方法、セッション管理システムおよびプログラム | |
| US6848000B1 (en) | System and method for improved handling of client state objects | |
| US20020046262A1 (en) | Data access system and method with proxy and remote processing | |
| US9628549B1 (en) | Method and system for controlling and accessing content servers | |
| US6672775B1 (en) | Cross-machine web page download and storage | |
| CN101136834B (zh) | 一种基于ssl vpn的链接改写方法和设备 | |
| US6408296B1 (en) | Computer implemented method and apparatus for enhancing access to a file | |
| JP2003288261A (ja) | データ転送装置、データ転送方法及びプログラム | |
| JP2003141002A (ja) | Ｕｒｌ長変換システム及びそのプログラム | |
| Wong | Web Client Programming with Perl | |
| JP2004246747A (ja) | 既存サービスのラッピング方法および装置 | |
| JP4988307B2 (ja) | コンテキスト・ベースのナビゲーション | |
| US6957247B1 (en) | Internet system | |
| Fisher | Spinning the Web: a guide to serving information on the World Wide Web | |
| EP1052827A2 (en) | Dynamic resource modification in a communication network | |
| JP4206206B2 (ja) | 情報資源の更新方法 | |
| US20080222157A1 (en) | Information providing method and information providing system | |
| TW531998B (en) | Method and system of enforcing the dispatching of IP datagrams on a plurality of servers according to a defined policy | |
| WO2010006700A1 (en) | Single point of entry server solution for world-wide-web annotation services with reduced latency |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060905 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061226 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070323 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070417 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070710 |
|
| 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: 20080819 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20080820 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080822 |
|
| 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: 20110905 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120905 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |