(57)【要約】【課題】マッシュアップによるＷｅｂサービスにおけるＣｏｏｋｉｅの良好な利用を可能にする技術を提供する。【解決手段】サーバから提供されるデータを利用したサービスをクライアントに提供するゲートウェイ装置は、サーバから指定される第１Ｃｏｏｋｉｅを、サーバを識別する識別情報を埋め込む所定の変換処理によって第２Ｃｏｏｋｉｅに変換する第１変換部と、クライアントから送信された第２Ｃｏｏｋｉｅを、変換処理の逆処理により第１Ｃｏｏｋｉｅに変換する第２変換部と、を有する。【選択図】図１
2019074835.tif 000002
【特許請求の範囲】
【請求項１】
サーバから提供されるデータを利用したサービスをクライアントに提供するゲートウェイ装置であって、
前記サーバから指定される第１Ｃｏｏｋｉｅを、前記サーバを識別する識別情報を埋め込む所定の変換処理によって第２Ｃｏｏｋｉｅに変換する第１変換部と、
前記クライアントから送信された第２Ｃｏｏｋｉｅを、前記変換処理の逆処理により第１Ｃｏｏｋｉｅに変換する第２変換部と、
を有するゲートウェイ装置。
【請求項２】
前記第２変換部は、
前記クライアントからの要求メッセージの送信先と、該要求メッセージに付与された前記第２Ｃｏｏｋｉｅに埋め込まれた識別情報が示すサーバとが一致すれば、該送信先に前記第２Ｃｏｏｋｉｅから復元した前記第１Ｃｏｏｋｉｅを前記第２Ｃｏｏｋｉｅの代わりに付与した前記要求メッセージを送信し、
前記要求メッセージの送信先と、該要求メッセージに付与された前記第２Ｃｏｏｋｉｅに埋め込まれた識別情報が示すサーバとが一致しなければ、該送信先に前記第２Ｃｏｏｋｉｅを削除した前記要求メッセージを送信する、
請求項１に記載のゲートウェイ装置。
【請求項３】
前記第２Ｃｏｏｋｉｅは、前記第１Ｃｏｏｋｉｅの所定位置に、前記サーバのドメイン名にハッシュ関数を適用して得た要約値に基づく追記符号を追記したものである、
請求項１に記載のゲートウェイ装置。
【請求項４】
前記第１ＣｏｏｋｉｅはＳｅｔ−Ｃｏｏｋｉｅヘッダで指定され、
前記第２ＣｏｏｋｉｅはＣｏｏｋｉｅヘッダに設定される、
請求項１に記載のゲートウェイ装置。
【請求項５】
前記第１変換部は、前記サーバからの前記第１Ｃｏｏｋｉｅがドメイン属性の要素を含んでいれば、該ドメイン属性の要素を前記ゲートウェイ装置を示す値に置換するか、あるいは該ドメイン属性の要素を削除する、
請求項１に記載のゲートウェイ装置。
【請求項６】
前記識別情報は、サブドメインを含むドメイン名であり、
前記第２変換部は、前記要求メッセージの送信先と一致するか否かの判定に、該要求メッセージに付与された前記第２Ｃｏｏｋｉｅに埋め込まれた前記識別情報から前記サブドメインを取り除いた値を用いる、
請求項２に記載のゲートウェイ装置。
【請求項７】
前記識別情報は、１つ以上のサブドメインを含むことが可能なドメイン名であり、
前記第２変換部は、前記要求メッセージの送信先と、該要求メッセージの前記第２Ｃｏｏｋｉｅに埋め込まれた前記ドメイン名が示すサーバとが一致するか否かの第１判定を行い、一致すれば、該サーバに前記第２Ｃｏｏｋｉｅから復元した前記第１Ｃｏｏｋｉｅを付与した前記要求メッセージを送信し、一致しなければ、前記ドメイン名がトップレベルドメインを示しているか否かの第２判定を行い、前記ドメイン名がトップレベルドメインを示していなければ、該ドメイン名からサブドメインを１つ取り除いて前記第１判定に戻り、トップレベルドメインを示していれば、前記送信先に、前記第２Ｃｏｏｋｉｅを削除した前記要求メッセージを送信する、
請求項６に記載のゲートウェイ装置。
【請求項８】
前記第１変換部は、前記第１Ｃｏｏｋｉｅがパス属性の要素を含んでいれば前記サーバのドメイン名と前記パス属性を含む文字列にハッシュ関数を適用して得た要約値にに基づく追記符号を、前記第１Ｃｏｏｋｉｅがパス属性の要素を含んでいなければ前記サーバのドメイン名にハッシュ関数を適用して得た要約値に基づく追記符号を、前記第１Ｃｏｏｋｉｅに追記して前記第２Ｃｏｏｋｉｅを生成し、
前記第２変換部は、前記クライアントからの要求メッセージの送信先のドメイン名と前記要求メッセージのパスとを含む文字列にハッシュ関数を適応して得た要約値または前記ドメイン名にハッシュ関数を適用して得た要約値のいずれかに基づく比較符号が、前記要求メッセージに付与された前記第２Ｃｏｏｋｉｅに含まれている追記符号と対応づけば、前記第２Ｃｏｏｋｉｅから前記追記符号を削除した前記第１Ｃｏｏｋｉｅを前記第２Ｃｏｏｋｉｅの代わりに付与した前記要求メッセージを前記送信先に送信し、前記比較符号が前記追記符号に対応づかなければ、前記第２Ｃｏｏｋｉｅを削除した前記要求メッセージを前記送信先に送信する、
請求項１に記載のゲートウェイ装置。
【請求項９】
サーバから提供されるデータを利用したサービスをクライアントに提供するゲートウェイ装置におけるＣｏｏｋｉｅ処理方法であって、
前記サーバから指定される第１Ｃｏｏｋｉｅを、前記サーバを識別する識別情報を埋め込む所定の変換処理によって第２Ｃｏｏｋｉｅに変換し、
前記クライアントから送信された第２Ｃｏｏｋｉｅを、前記変換処理の逆処理により第１Ｃｏｏｋｉｅに変換する、
Ｃｏｏｋｉｅ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスのマッシュアップなどを実現するＡＰＩゲートウェイに関する。
【背景技術】
【０００２】
近年、マッシュアップによりＷｅｂサービスを提供する仕組みが注目されている。複数のＷｅｂＡＰＩから取得されるデータを組み合わせることで新たなＷｅｂサービスを実現することができる。業務システム、ソーシャルネットワーク、他Ｗｅｂサービスなどが提供する様々なＷｅｂＡＰＩ（以下、単に「ＡＰＩ」ともいう）を利用することができ、全てを最初から開発するスクラッチ開発に比べ、短期かつ低コストでサービスを実現することができる。
【０００３】
例えば、特許文献１では、ＡＰＩ集約装置が、ＡＰＩの組み合わせ実行回数などに基づいて、マッシュアップするＡＰＩを決定する方式を開示している。一方、特許文献１には、マッシュアップされるデータを提供するＷｅｂサーバ（以下、単に「サーバ」ともいう）によるＨＴＴＰ−Ｃｏｏｋｉｅ（以下、単に「Ｃｏｏｋｉｅ」ともいう）の利用について何ら言及されていない。
【０００４】
従来から、サーバはＣｏｏｋｉｅを利用してクライアントを識別し、ユーザのトラッキングやアクセス管理を実現してきた。具体的には、サーバはクライアント（具体的にはクライアント上のＷｅｂブラウザ）からのＨＴＴＰ要求に対し、要求されたコンテンツにＳｅｔ−ＣｏｏｋｉｅでＣｏｏｋｉｅを指定して応答する。当該クライアントは次回以降の当該サーバに対して送信するＨＴＴＰ要求に、Ｓｅｔ−Ｃｏｏｋｉｅで指定されたＣｏｏｋｉｅを付与する。サーバはこのＣｏｏｋｉｅを使用してクライアントを識別し、必要に応じてクライアント毎の処理を実行する。
【０００５】
しかし、マッシュアップにより開発されたＷｅｂサービスでは、マッシュアップされるデータを提供するサーバとクライアントとの間にＡＰＩゲートウェイが存在する。その場合、サーバが発行するＳｅｔ−Ｃｏｏｋｉｅや、クライアントが送信するＣｏｏｋｉｅを当該Ｗｅｂサービスでどう扱うかについて特に規定がなく、マッシュアップによるＷｅｂサービスの開発者次第である。そのためサーバはＣｏｏｋｉｅを利用できる可能性もあれば利用できない可能性もある。
【０００６】
サーバが確実にＣｏｏｋｉｅを利用可能にするためには、ＡＰＩゲートウェイでサーバからのＳｅｔ−Ｃｏｏｋｉｅを一律に転送する場合、クライアントがＣｏｏｋｉｅを正しいものとして受け取れるよう、Ｓｅｔ−Ｃｏｏｋｉｅのｄｏｍａｉｎ属性値を、ＡＰＩゲートウェイのドメインに置き換える必要がある。特許文献２には、ＳＰＤＹアクセラレータがサーバの応答に含まれるＳｅｔ−Ｃｏｏｋｉｅのｄｏｍａｉｎ属性値を異なるドメインに置き換える方式が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１６−１５１８８５号公報
【特許文献２】特開２０１４−１９９５６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、ＡＰＩゲートウェイにて全てのＳｅｔ−Ｃｏｏｋｉｅのｄｏｍａｉｎ属性値を同じＡＰＩゲートウェイのドメインに置き換えてしまうと、データがマッシュアップされる複数サービス間でＣｏｏｋｉｅが分離できないという問題がある。例えば、サーバ間で重複するＣｏｏｋｉｅ名を使用していた場合、クライアントは後から読み込んだＳｅｔ−Ｃｏｏｋｉｅにより同名Ｃｏｏｋｉｅを上書きしてしまう。
【０００９】
また、クライアントからＣｏｏｋｉｅを付与したＨＴＴＰ要求を受信したＡＰＩゲートウェイは該Ｃｏｏｋｉｅがどのサーバから発行されたものか判別できない。
【００１０】
本発明の目的は、マッシュアップによるＷｅｂサービスにおけるＣｏｏｋｉｅの良好な利用を可能にする技術を提供することである。
【課題を解決するための手段】
【００１１】
本発明の一態様によるゲートウェイ装置は、サーバから提供されるデータを利用したサービスをクライアントに提供するゲートウェイ装置であって、前記サーバから指定される第１Ｃｏｏｋｉｅを、前記サーバを識別する識別情報を埋め込む所定の変換処理によって第２Ｃｏｏｋｉｅに変換する第１変換部と、前記クライアントから送信された第２Ｃｏｏｋｉｅを、前記変換処理の逆処理により第１Ｃｏｏｋｉｅに変換する第２変換部と、を有する。
【発明の効果】
【００１２】
サーバから指定されたＣｏｏｋｉｅをサーバの識別情報を埋め込む変換処理で変換し、クライアントからのＣｏｏｋｉｅを逆変換処理により元の形式のＣｏｏｋｉｅに戻す。ゲートウェイ装置で置き換えたＣｏｏｋｉｅがクライアントに送られるので確実に利用することが可能であり、サーバの識別情報を埋め込む変換処理でＣｏｏｋｉｅを置き換えるので、Ｃｏｏｋｉｅを指定したサーバを特定することが可能である。
【図面の簡単な説明】
【００１３】
【図１】実施例１によるＷｅｂサービスシステムのブロック図である。
【図２】ＡＰＩゲートウェイ１００を実現する電子計算機の物理構成を示すブロック図である。
【図３】Ｓｅｔ−Ｃｏｏｋｉｅヘッダの変換について説明するための図である。
【図４】Ｃｏｏｋｉｅヘッダの変換について説明するための図である。
【図５】実施例１によるＳｅｔ−Ｃｏｏｋｉｅ変換処理のフローチャートである。
【図６】実施例１によるＣｏｏｋｉｅ付与判定処理のフローチャートである。
【図７】実施例１によるＷｅｂサービスの提供の様子を示すシーケンス図である。
【図８】実施例２によるＣｏｏｋｉｅ付与判定処理のフローチャートである。
【図９】実施例３によるＳｅｔ−Ｃｏｏｋｉｅ変換処理のフローチャートである。
【図１０】実施例３によるＣｏｏｋｉｅ付与判定処理のフローチャートである。
【発明を実施するための形態】
【００１４】
以下、実施例について図面を用いて説明する。なお、以下の実施例では、クライアント、サーバ、ＡＰＩゲートウェイ間の通信プロコルとしてＨＴＴＰを利用した場合を例示する。しかし、ＨＴＴＰと同様の機能を備える異なる通信プロトコルを利用しても良い。また、以下の実施例では、クライアントとＡＰＩゲートウェイとサーバがそれぞれ１台の装置上で動作する場合を例示する。しかし、クライアントとＡＰＩゲートウェイとサーバの各機能が実装される物理的な位置は問わない。
【実施例１】
【００１５】
図１は、実施例１によるＷｅｂサービスシステムのブロック図である。図１を参照すると、Ｗｅｂサービスシステムは、サーバ３００−１〜３００−Ｎ、クライアント２００、およびＡＰＩゲートウェイ１００を有している。ＡＰＩゲートウェイ１００は、サーバ３００−１〜３００−Ｎとクライアント２００の間にあり、サーバ３００−１〜３００−Ｎとは通信ネットワークＮ１０を介して接続され、クライアント２００とは通信ネットワークＮ２０を介して接続される。
【００１６】
通信ネットワークＮ１０、Ｎ２０は、例えばインターネットや社内ネットワーク（イントラネット）である。クライアント２００は例えばＷｅｂブラウザである。サーバ３００−１〜３００−Ｎは例えばＷｅｂサーバである。
【００１７】
クライアント２００はＡＰＩゲートウェイ１００にＨＴＴＰ要求１０−１を送信し、ＡＰＩゲートウェイ１００からＨＴＴＰ応答２０−２を受信する。
【００１８】
サーバ３００−１〜３００−ＮはＡＰＩゲートウェイ１００からＨＴＴＰ要求１０−２を受信し、ＨＴＴＰ要求１０−２の内容に応じたコンテンツをＨＴＴＰ応答２０−１として応答する。ＨＴＴＰ要求１０−２は、例えばＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）である。ＨＴＴＰ応答２０−１のコンテンツは、例えばＨｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＨＴＭＬ）ファイルや、ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）である。ＪａｖａＳｃｒｉｐｔは登録商標である。
【００１９】
ＡＰＩゲートウェイ１００は、マッシュアップ処理部１１０、第１変換部１４０、第２変換部１３０、および記憶部１２０とを備える。
【００２０】
記憶部１２０は、マッシュアップにより実現されるＷｅｂサービスの具体的処理を記述した処理定義Ｄ１０と、ハッシュ関数Ｄ２０とを記憶する。記憶部１２０は例えば、メモリ、ファイルシステム、あるいはそれらを複合した構成である。
【００２１】
処理定義Ｄ１０は、マッシュアップ開発者Ｕ１０により作成され、予め登録される。処理定義Ｄ１０は、例えばＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたプログラムである。また、ハッシュ関数Ｄ２０は、例えばＳｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ２（ＳＨＡ２）などである。
【００２２】
マッシュアップ処理部１１０は、クライアント２００からＨＴＴＰ要求１０−１の受信を契機として処理をおこなう。
【００２３】
マッシュアップ処理部１１０は、マッシュアップ開発者Ｕ１０が作成した処理定義Ｄ１０に従い、サーバ３００−１〜３００−Ｎに対してどのようなＨＴＴＰ要求１０−２を送信するか、サーバ３００−１〜３００−Ｎから受信したＨＴＴＰ応答２０−１に基づきクライアント２００へどのようなＨＴＴＰ応答２０−２を送信するかを決定する。
【００２４】
図１には、ＨＴＴＰ要求１０−２、ＨＴＴＰ要求１０−２の宛先とするサーバ３００−１〜３００−Ｎ、およびＨＴＴＰ応答２０−１がそれぞれ1つずつ示されているが、複数であってもよい。各サーバに送信するＨＴＴＰ要求１０−２はそれぞれ異なってもよい。また、各サーバから受信するＨＴＴＰ応答２０−１の内容（ＵＲＬ、ＪＳＯＮなど）もそれぞれ異なってもよい。以下、サーバ３００−１〜３００−Ｎを個々に区別する必要がない場合にはサーバ３００と記載することがある。
【００２５】
ＡＰＩゲートウェイ１００がサーバ３００に送信するＨＴＴＰ要求１０−２は、マッシュアップ処理部１１０から第２変換部１３０を経由してサーバ３００に送信される。また、サーバ３００からＡＰＩゲートウェイ１００への応答は、第１変換部１４０を経由してマッシュアップ処理部１１０に受信される。
【００２６】
マッシュアップ処理部１１０は、処理定義Ｄ１０の内容にかかわらず、クライアント２００からのＨＴＴＰ要求１０−１に含まれるＣｏｏｋｉｅヘッダに処理を加えず、そのままのＣｏｏｋｉｅヘッダを第２変換部１３０に送る。
【００２７】
また、マッシュアップ処理部１１０は、第１変換部１４０から受けたＨＴＴＰ応答２０−１に含まれる全てのＳｅｔ−Ｃｏｏｋｉｅヘッダを、クライアントへ送信するＨＴＴＰ応答２０−２に付与する。
【００２８】
第１変換部１４０は、サーバ３００から受信したＨＴＴＰ応答２０−１が含むＳｅｔ−ＣｏｏｋｉｅヘッダをＳｅｔ−Ｃｏｏｋｉｅ変換処理により変換し、マッシュアップ処理部１１０に送る。具体的には、Ｓｅｔ−ＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名とｄｏｍａｉｎ属性値とを書き換える。変換前後のＳｅｔ−Ｃｏｏｋｉｅヘッダは図３を用いて後述する。Ｓｅｔ−Ｃｏｏｋｉｅ変換処理のフローは図５を用いて後述する。
【００２９】
第２変換部１３０は判定部１３１と復元部１３２を有している。
【００３０】
判定部１３１は、マッシュアップ処理部１１０から受けたサーバ３００宛のＨＴＴＰ要求が備える各Ｃｏｏｋｉｅヘッダについて、サーバ３００に送信するＨＴＴＰ要求１０−２に当該Ｃｏｏｋｉｅヘッダを付与するか否かをＣｏｏｋｉｅ付与判定処理により判定する。変換前後のＣｏｏｋｉｅヘッダは図４を用いて後述する。Ｃｏｏｋｉｅ付与判定処理のフローは図６を用いて後述する。
【００３１】
判定部１３１は、Ｃｏｏｋｉｅ付与判定処理による判定の結果、ＨＴＴＰ要求１０−２に付与すると判断した場合には当該ＣｏｏｋｉｅヘッダをＨＴＴＰ要求に付与し、ＨＴＴＰ要求１０−２に付与しないと判断したＣｏｏｋｉｅヘッダをＨＴＴＰ要求から削除する。
【００３２】
復元部１３２は、判定部１３１にてＨＴＴＰ要求に付与されたＣｏｏｋｉｅヘッダを変換する。具体的には、Ｃｏｏｋｉｅ名に対して第１変換部１４０と逆の変換を行う。
【００３３】
図２は、ＡＰＩゲートウェイ１００を実現する電子計算機の物理構成を示すブロック図である。図２を参照すると、電子計算機は、プログラムを実行し、各処理機能を実現するプロセッサＨ２０１と、実行するプログラムやデータを一時的に保持するメモリ装置Ｈ２０２と、外部からの指示や情報を入力するための入力装置Ｈ２０３と、プログラムの実体、指示、情報等を格納し、データの記録に使用されるディスク装置Ｈ２０４と、外部装置とのデータのやり取りを制御する通信制御装置Ｈ２０５と、装置内部でデータのやり取りを行うためのバスなどの内部通信線Ｈ２０６と、電子計算機の内部と外部装置とのデータのやり取りするための外部通信回線Ｈ２０７を備える。
【００３４】
上記プログラムは予め、電子計算機内のメモリ装置Ｈ２０２またはディスク装置Ｈ２０４に格納されていても良いし、必要なときに、上記電子計算機が利用可能な、着脱可能な記憶媒体から、または通信媒体（ネットワーク、または、ネットワークを伝播する搬送波またはデジタル信号）を介して他の装置から、導入されてもよい。
【００３５】
また、各処理機能の処理内容は、ディスク装置Ｈ２０４に格納されているプログラムを、プロセッサＨ２０１が読み出して実行することにより、具現化されるものである。
【００３６】
図３は、Ｓｅｔ−Ｃｏｏｋｉｅヘッダの変換について説明するための図である。図３の上段には、サーバ３００からＡＰＩゲートウェイ１００に送信されるＨＴＴＰ応答２０−１に付加される変換前のＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０１の一例が示されている。図３の下段には、第１変換部１４０により書き換えられた変換後のＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０２の一例である。書き換えられたＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０２は、ＡＰＩゲートウェイ１００からクライアント２００に送信されるＨＴＴＰ応答２０−２に付加される。
【００３７】
Ｓｅｔ−ＣｏｏｋｉｅヘッダＳＣ０１、ＳＣ０２は、一例として、Ｃｏｏｋｉｅ名ＳＣ１０、Ｃｏｏｋｉｅ値ＳＣ２０、ｄｏｍａｉｎ属性ＳＣ３０、およびｄｏｍａｉｎ属性値を含んでいる。
【００３８】
ただし、図３に示したＳｅｔ−Ｃｏｏｋｉｅヘッダは一例であり、図３に示した要素の他にＲＦＣ６２６５で定められるその他の属性を要素として備えても良い。しかし、第１変換部１４０は、その他の属性については何ら変更しない。その他の属性には例えばＳｅｃｕｒｅ属性がある。
【００３９】
上段に示された変換前のＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０１のＣｏｏｋｉｅ名ＳＣ１０は「key0」である。
【００４０】
下段に示された変換後のＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０２のＣｏｏｋｉｅ名ＳＣ１０−２は、変換前のＣｏｏｋｉｅ名ＳＣ１０「key0」の末尾に、セパレート文字列ＳＰ１０「-」と、ハッシュ関数Ｄ２０により算出された要約値Ｈ１０「8s14snLGv2」とが追加されている。
【００４１】
また、変換前のＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０１のｄｏｍａｉｎ属性値ＳＣ４０は、サーバ３００のドメイン名「www.example.com」であるが、変換後のＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０２のｄｏｍａｉｎ属性値ＳＣ４０−２は、ＡＰＩゲートウェイ１００のドメイン名「gateway.com」に書き換えられている。
【００４２】
なお、本実施例では、ＡＰＩゲートウェイ１００は、一例として、ｄｏｍａｉｎ属性値を書き換えることにしている。しかし、ＡＰＩゲートウェイ１００は、ｄｏｍａｉｎ属性値を書き換えずに、ｄｏｍａｉｎ属性の要素を削除しても良い。
【００４３】
また、ｄｏｍａｉｎ属性ＳＣ３０は省略されても良いので、サーバ３００からのＨＴＴＰ応答２０−１にｄｏｍａｉｎ属性ＳＣ３０が含まれていないことも考えられる。その場合は、第１変換部１４０は、ｄｏｍａｉｎ属性値ＳＣ４０を書き換える処理は実施しない。
【００４４】
図４は、Ｃｏｏｋｉｅヘッダの変換について説明するための図である。図４の上段には、クライアント２００からのＨＴＴＰ要求１０−１に含まれる変換前のＣｏｏｋｉｅヘッダＣ０１の一例が示されている。図４の下段には、第２変換部１３０により書き換えられた変換後のＣｏｏｋｉｅヘッダＣ０２の一例が示されている。変換後のＣｏｏｋｉｅヘッダＣ０２は、ＡＰＩゲートウェイ１００からサーバ３００に送信されるＨＴＴＰ要求１０−２に付加される。
【００４５】
変換前のＣｏｏｋｉｅヘッダＣ０１のＣｏｏｋｉｅ名Ｃ１０には、ＡＰＩゲートウェイ１００からクライアント２００へのＳｅｔ−ＣｏｏｋｉｅヘッダＳＣ０２で指定されたＣｏｏｋｉｅ名ＳＣ１０−０２と同じ名前が設定される。Ｃｏｏｋｉｅ名Ｃ１０の末尾には、セパレート文字列ＳＰ１０と、要約値Ｈ１０とが記載されている。
【００４６】
第２変換部１３０により書き換えられた変換後のＣｏｏｋｉｅヘッダＣ０１のＣｏｏｋｉｅ名Ｃ１０−２は、ＣｏｏｋｉｅヘッダＣ０１のＣｏｏｋｉｅ名Ｃ１０の末尾から、セパレート文字列ＳＰ１０と要約値Ｈ１０が取り除かれたものとなっている。
【００４７】
なお、図４に示したＣｏｏｋｉｅヘッダは一例であり、ＣｏｏｋｉｅヘッダにはＲＦＣ６２６５で定められるその他の属性を要素として含んでもよいが、第２変換部１３０は、その他の属性については何ら変更しない。その他の属性には例えばＳｅｃｕｒｅ属性がある。
【００４８】
図５は、実施例１によるＳｅｔ−Ｃｏｏｋｉｅ変換処理のフローチャートである。第１変換部１４０がＳｅｔ−Ｃｏｏｋｉｅヘッダを書き換える処理の一例が示されている。本処理は、サーバ３００−１〜３００−Ｎから受信したＨＴＴＰ応答２０−１が備える各Ｓｅｔ−Ｃｏｏｋｉｅヘッダを処理の対象とする。
【００４９】
第１変換部１４０は、ＨＴＴＰ応答の送信元サーバのドメイン名にハッシュ関数Ｈ１０を適用し、要約値を算出する（ステップＦ２００）。そして、第１変換部１４０は、事前に定めたセパレータ文字列ＳＰ１０とステップＦ２００で算出した要約値とを結合し、追記文字列とする（ステップＦ２１０）。セパレータ文字列には要約値に出現しない文字列（１文字の場合を含む）、例えば「_」（アンダースコア）を利用する。
【００５０】
続いて、第１変換部１４０は、ステップＦ２１０で算出した追記文字列に対し、ＲＦＣ３９８６が定めるパーセントエンコードを施し、追記符号とする（ステップＦ２２０）。ＲＦＣ７２３０によりＨＴＴＰヘッダで利用可能な文字は限定されているため、ステップＦ２２０にて追記文字列を利用可能な文字の追記符号に変換する。
【００５１】
第１変換部１４０は、ステップＦ２２０で算出した追記符号をＳｅｔ−ＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名の末尾に追加する（ステップＦ２３０）。
【００５２】
第１変換部１４０は、Ｓｅｔ−Ｃｏｏｋｉｅヘッダがｄｏｍａｉｎ属性を備えるか否かを判断する（ステップＦ２４０）。Ｓｅｔ−Ｃｏｏｋｉｅヘッダがｄｏｍａｉｎ属性を備える場合、第１変換部１４０は、そのｄｏｍａｉｎ属性値をＡＰＩゲートウェイ１００を示すドメイン属性値に置換する（ステップＦ２５０）。Ｓｅｔ−Ｃｏｏｋｉｅヘッダがｄｏｍａｉｎ属性を備えない場合、第１変換部１４０は、何もせずに処理を終了する。
【００５３】
なお、クライアント２００の仕様が、Ｓｅｔ−Ｃｏｏｋｉｅヘッダにｄｏｍａｉｎ属性の要素が存在しないときには接続先のドメインをｄｏｍａｉｎ属性値として利用するというものである場合がある。その場合は、ＡＰＩゲートウェイ１００はｄｏｍａｉｎ属性値を書き換えずにｄｏｍａｉｎ属性とｄｏｍａｉｎ属性値を単に削除しても良い。
【００５４】
図６は、実施例１によるＣｏｏｋｉｅ付与判定処理のフローチャートである。図６には、判定部１３１が、サーバ３００へのＨＴＴＰ要求にＣｏｏｋｉｅヘッダを付与するか否か判定する処理の一例が示されている。判定部１３１は、マッシュアップ処理部１１０から受け取ったＨＴＴＰ要求に１つ以上のＣｏｏｋｉｅヘッダが含まれている場合、各Ｃｏｏｋｉｅヘッダを対象に本処理を実施する。
【００５５】
まず、判定部１３１は、マッシュアップ処理部１１０が作成したＨＴＴＰ要求の送信先サーバのドメイン名にハッシュ関数Ｈ１０を適用し、要約値を算出する（ステップＦ１００）。続いて、判定部１３１は、事前に定めたセパレータ文字列ＳＰ１０とステップＦ１００で算出した要約値とを結合し、比較文字列とする（ステップＦ１１０）。
【００５６】
判定部１３１は、ステップＦ１１０で算出した比較文字列に対し、ＲＦＣ３９８６が定めるパーセントエンコードを施し、比較符号とする（ステップＦ１２０）。ＲＦＣ７２３０にてＨＴＴＰヘッダで利用可能な文字は限定されているため、本処理により比較文字列を利用可能な文字の比較符号に変換する。
【００５７】
判定部１３１は、ステップＦ１２０で算出した比較符号と、Ｃｏｏｋｉｅ名とが後方一致するか否か文字列の比較を行う（ステップＦ１３０）。後方一致はＣｏｏｋｉｅ名の末尾を含む部分が比較符号と一致するか否かで判定される。比較符号とＣｏｏｋｉｅ名とが後方一致すれば、すなわち、比較符号がＣｏｏｋｉｅ名の末尾の文字列と一致すれば、判定部１３１は、該ＣｏｏｋｉｅをＨＴＴＰ要求に付与すると判定し（ステップＦ１４０）。後方一致しなければ、判定部１３１は、該Ｃｏｏｋｉｅヘッダを付与しないと判定し、ＨＴＴＰ要求から取り除く（ステップＦ１５０）。
【００５８】
Ｃｏｏｋｉｅ付与判定処理は以上である。
【００５９】
ステップＦ１５０にて、ＨＴＴＰ要求にＣｏｏｋｉｅヘッダを付与すると判定された場合、復元部１３２は、ＨＴＴＰ要求のＣｏｏｋｉｅヘッダを書き換え、当該ＨＴＴＰ要求をサーバ３００へ送信する。Ｃｏｏｋｉｅヘッダの書き換えは、具体的には、ＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名の末尾から遡ってセパレート文字列までの削除である。
【００６０】
ステップＦ１５０にて、ＨＴＴＰ要求にＣｏｏｋｉｅヘッダを付与しないと判定された場合、復元部１３２は、Ｃｏｏｋｉｅヘッダが削除されたＨＴＴＰ要求をそのままサーバ３００に送信する。
【００６１】
図７は、実施例１によるＷｅｂサービスの提供の様子を示すシーケンス図である。図７の例では、クライアント２００がＡＰＩゲートウェイ１００に対してＨＴＴＰ要求を送信する。ＡＰＩゲートウェイ１００は、サーバ３００−１から提供されるデータとサーバ３００−２から提供されるデータをマッシュアップしたデータをクライアント２００に提供する。
【００６２】
本実施例において、サーバ３００−１のドメイン名は「A.com」とし、サーバ３００−２のドメイン名は「B.com」とし、ＡＰＩゲートウェイのドメイン名は「G.com」とする。
【００６３】
図７を参照すると、まず、クライアント２００がＡＰＩゲートウェイ１００宛にＨＴＴＰ要求１０−１を送信する（ステップＳ１００）。このとき、ＨＴＴＰ要求１０−１はＣｏｏｋｉｅヘッダを含まないものとする。
【００６４】
ＡＰＩゲートウェイ１００がＨＴＴＰ要求１０−１を受信すると、マッシュアップ処理部１１０が処理定義Ｄ１０に従い、サーバ３００−１宛のＨＴＴＰ要求１０−２と、サーバ３００−２宛のＨＴＴＰ要求１０−２を作成し、それらを送信する（ステップＳ１０２、Ｓ１０６）。
【００６５】
当該ＨＴＴＰ要求１０−２はＣｏｏｋｉｅヘッダを含まないため、第２変換部１３０の判定部１３１と復元部１３２は、当該ＨＴＴＰ要求１０−２に対して何ら処理を実施しない。
【００６６】
サーバ３００−１、３００−２は、それぞれステップＳ１０２、Ｓ１０６で送信されたＨＴＴＰ要求を受信し、要求されたコンテンツのデータをＨＴＴＰ応答により応答する（ステップＳ１０４、Ｓ１０８）。このとき、サーバ３００−１とサーバ３００−２はいずれも各ＨＴＴＰ応答にＳｅｔ−Ｃｏｏｋｉｅヘッダを付与するものとする。
【００６７】
本例では、サーバ３００−１は、Ｃｏｏｋｉｅ名「key」、Ｃｏｏｋｉｅ値「abc」、ｄｏｍａｉｎ属性値「A.com」を備えるＳｅｔ−ＣｏｏｋｉｅヘッダをＨＴＴＰ応答に付与するものとする。また、サーバ３００−２は、Ｃｏｏｋｉｅ名「key」、Ｃｏｏｋｉｅ値「def」、ｄｏｍａｉｎ属性値「B.com」を備えるＳｅｔ−ＣｏｏｋｉｅヘッダをＨＴＴＰ応答に付与するとする。
【００６８】
ＡＰＩゲートウェイ１００の第１変換部１４０は、ステップＳ１０４、Ｓ１０８にてＳｅｔ−Ｃｏｏｋｉｅヘッダを備えるＨＴＴＰ応答を受け取り、Ｓｅｔ−ＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名とｄｏｍａｉｎ属性値を書き換える（ステップＳ１１０）。具体的な処理は図５に示した通りである。
【００６９】
マッシュアップ処理部１１０は、処理定義Ｄ１０に従い、サーバ３００−１とサーバ３００−２からのＨＴＴＰ応答に基づきＨＴＴＰ応答を生成し、クライアント２００に送信する（ステップＳ１１２）。このＨＴＴＰ応答には、第１変換部１４０によって書き換えられたＳｅｔ−Ｃｏｏｋｉｅヘッダが付加されている。
【００７０】
クライアント２００は、ステップＳ１１２で送信されたＨＴＴＰ応答を受信すると、当該ＨＴＴＰ応答のＳｅｔ−Ｃｏｏｋｉｅヘッダで指定されたＣｏｏｋｉｅを記録する（ステップＳ１１４）。
【００７１】
更に、クライアント２００は、ステップＳ１１４にて記録したＣｏｏｋｉｅ名を記憶した状態でＡＰＩゲートウェイ１００に対してステップＳ１００と同様にＨＴＴＰ要求を送信する場合、当該ＨＴＴＰ要求にＣｏｏｋｉｅヘッダを付与する（ステップＳ１２０）。通知すべきＣｏｏｋｉｅ名が複数ある場合、複数のＣｏｏｋｉｅ名を１つのＣｏｏｋｉｅヘッダ内にセミコロンで区切って列挙する。
【００７２】
ステップＳ１２０で送信されたＨＴＴＰ要求をＡＰＩゲートウェイ１００が受信し、マッシュアップ処理部１１０がサーバ３００−１とサーバ３００−２にＨＴＴＰ要求を送信する際、判定部１３１は、ステップＳ１２０で受信されたＨＴＴＰ要求に含まれるＣｏｏｋｉｅヘッダについてＣｏｏｋｉｅ付与判定処理を行う（ステップＳ１２２）。Ｃｏｏｋｉｅ付与判定処理は図６に示した通りである。
【００７３】
ステップＳ１２２の処理に続いて、復元部１３２は、ＨＴＴＰ要求に付与されているＣｏｏｋｉｅについて、各Ｃｏｏｋｉｅ名の末尾からセパレータ文字列ＳＰ１０まで（セパレータ文字列ＳＰ１０を含む）を取り除く。
【００７４】
ステップＳ１２２とステップＳ１２４の処理により、サーバ３００−１と、サーバ３００−２には、それぞれがステップＳ１０４、ステップＳ１０８のＳｅｔ−Ｃｏｏｋｉｅヘッダにて指定されたＣｏｏｋｉｅ名のＣｏｏｋｉｅヘッダのみが送信される（ステップＳ１２６、Ｓ１２８）。
【００７５】
以上、本実施例によれば、ＡＰＩゲートウェイ１００は、サーバ３００から提供されるデータを利用したサービスをクライアントに提供するゲートウェイ装置である。第１変換部１４０は、サーバ３００からＨＴＴＰ応答に付加されたＳｅｔ−Ｃｏｏｏｋｉｅヘッダにて指定されるＣｏｏｋｉｅ（第１Ｃｏｏｋｉｅ）を、そのサーバ３００を識別する識別情報であるｄｏｍａｉｎ名を埋め込む所定の変換処理によって第２Ｃｏｏｋｉｅに変換する。この第２Ｃｏｏｋｉｅがクライアント２００に送られる。クライアント２００は、この第２ＣｏｏｋｉｅをＨＴＴＰ要求１０−１に付加するＣｏｏｋｉｅヘッダに設定して送信することになる。第２変換部１３０は、クライアント２００からのＨＴＴＰ要求に付加されたＣｏｏｋｉｅヘッダに設定された第２Ｃｏｏｋｉｅを、第１変換部１４０の変換処理の逆処理により第１Ｃｏｏｋｉｅに変換する。この第１ＣｏｏｋｉｅがＡＰＩゲートウェイ１００からのＨＴＴＰ要求１０−２のＣｏｏｋｉｅヘッダにてサーバ３００に送られる。このように、サーバ３００から指定されたＣｏｏｋｉｅをサーバ３００の識別情報を埋め込む変換処理で変換し、クライアント２００からのＣｏｏｋｉｅを逆変換処理により元の形式のＣｏｏｋｉｅに戻す。ＡＰＩゲートウェイ１００で置き換えたＣｏｏｋｉｅがクライアント２００に送られるので確実に利用することが可能である。しかも、サーバ３００の識別情報を埋め込む変換処理でＣｏｏｋｉｅを置き換えるので、Ｃｏｏｋｉｅを指定したサーバ３００を特定することが可能である。なお、第１ＣｏｏｋｉｅはＳｅｔ−Ｃｏｏｋｉｅヘッダで指定され、第２ＣｏｏｋｉｅはＣｏｏｋｉｅヘッダに設定される。
【００７６】
また、本実施例によれば、第２変換部１３０は、クライアント２００からのＨＴＴＰ要求（要求メッセージ）の送信先と、その要求メッセージに付与された第２Ｃｏｏｋｉｅに埋め込まれた識別情報が示すサーバ３００とが一致すれば、その送信先に第２Ｃｏｏｋｉｅから復元した第１Ｃｏｏｋｉｅを第２Ｃｏｏｋｉｅの代わりに付与した要求メッセージを送信する。また、第２変換部１３０は、要求メッセージの送信先と、その要求メッセージに付与された第２Ｃｏｏｋｉｅに埋め込まれた識別情報が示すサーバ３００とが一致しなければ、その送信先に第２Ｃｏｏｋｉｅを削除した要求メッセージを送信する。Ｃｏｏｋｉｅ情報がそのＣｏｏｋｉｅ名を指定したサーバ３００のみに送信されるので、サーバ３００間でのＣｏｏｋｉｅ情報の漏洩を防止することができる。
【００７７】
また、本実施例によれば、第２Ｃｏｏｋｉｅは、第１Ｃｏｏｋｉｅの所定位置に、サーバ３００のドメイン名にハッシュ関数を適用して得た要約値に基づく追記符号を追記したものである。所定位置の文字列を追記あるいは削除することで容易にＣｏｏｋｉｅを変換することができる。また、Ｃｏｏｋｉｅに追記する追記符号をハッシュ関数による要約値を基に作成することによりＣｏｏｋｉｅ情報の改ざんを抑制することができる。
【００７８】
また、本実施例によれば、第１変換部１４０は、サーバ３００からの第１Ｃｏｏｋｉｅがドメイン属性の要素を含んでいれば、そのドメイン属性の要素をＡＰＩゲートウェイ１００（ゲートウェイ装置）を示す値に置換するか、あるいはそのドメイン属性の要素を削除する。クライアントは、Ｃｏｏｋｉｅにドメイン属性の要素が含まれていれば、そこに設定されたサーバ３００がＣｏｏｋｉｅを指定したと解釈し、Ｃｏｏｋｉｅにドメイン属性の要素が含まれていなければ、メッセージの送信元がＣｏｏｋｉｅを指定したと解釈する。ドメイン属性の要素をＡＰＩゲートウェイ１００を示す値に置換するか、あるいは、ドメイン属性の要素を削除することで、不整合を防止することができる。
【００７９】
本実施例に用いた方法以外にもサーバ３００間でＣｏｏｋｉｅを分離する方法は考えられる。例えば、ＡＰＩゲートウェイがサービス間でＣｏｏｋｉｅを分離するために、ＡＰＩゲートウェイがルックアップテーブルを備える方式が考えられる。具体的には、ＡＰＩゲートウェイはサーバから受けたＣｏｏｋｉｅ名をユニークな値（ユニークＩＤ）に置換し、ユニークＩＤと元のＣｏｏｋｉｅ名とＣｏｏｋｉｅ発行元サーバとの組をルックアップテーブルに登録する。ＡＰＩゲートウェイは、クライアントからのＨＴＴＰ要求が備えるＣｏｏｋｉｅのＣｏｏｋｉｅ名を基にルックアップテーブルを参照して、Ｃｏｏｋｉｅ名を元の値に置換し、発行元サーバにＨＴＴＰ要求を送信することが考えられる。
【００８０】
しかし、ＡＰＩゲートウェイにそのようなルックアップテーブルを備えると、ＡＰＩゲートウェイを複数台設置し、それらでＨＴＴＰ要求を分散処理しようとした場合、各ＡＰＩゲートウェイが個別に備えるルックアップテーブルを同期できない。ＨＴＴＰ要求を分散処理することができず複数のＡＰＩゲートウェイを設けたことによるスケーラビリティが損なわれる。
【００８１】
また、クライアントに保存されたＣｏｏｋｉｅは、ブラウザを終了した場合や、保存可能な最大数を超えた場合などのクライアント都合のタイミングによって削除される。そのため、ＡＰＩゲートウェイではルックアップテーブルのレコードを削除可能かどうか判断できない。ルックアップテーブルからレコードを削除しなければ、レコードが単調増加し、ルックアップテーブルが肥大する。その結果、ルックアップテーブル参照処理時間が増加したり、メモリが不足したりすることが考えられる。
【００８２】
一方、本実施例によれば、複数のサービスをマッシュアップするようなＡＰＩゲートウェイにおいて、ルックアップテーブルを備えることなく、サービス間でＣｏｏｋｉｅを分離することができる。これにより、ＡＰＩゲートウェイはスケーラビリティを保ちつつ、サーバはＣｏｏｋｉｅを確実に利用することができる。
【００８３】
なお、本実施例では、Ｃｏｏｋｉｅの変換方法として、追記符号をＳｅｔ−ＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名の末尾に追加する例を示したが、これに限定されることはない。追記符号はＣｏｏｋｉｅ名の予め定められた位置に追記すればよく、その位置は任意である。例えば、追記符号をＳｅｔ−ＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名の先頭に追加することにしてもよい。その場合には後方一致の判定の代わりに前方一致の判定を行えばよい。
【実施例２】
【００８４】
実施例１は、ＡＰＩゲートウェイ１００がマッシュアップする各サーバ３００がそれぞれ自身の利用するＣｏｏｋｉｅを指定することを可能にする例を示した。実施例２では、サーバ３００がＣｏｏｋｉｅを複数のサブドメイン間で共有するために、Ｓｅｔ−Ｃｏｏｋｉｅヘッダのｄｏｍａｉｎ属性値として自身のドメインよりも浅いドメインを指定するのに対応可能とする例を示す。実施例２では、ＡＰＩゲートウェイはサーバが意図したとおりにＣｏｏｋｉｅをサブドメイン間で共有可能にする。
【００８５】
実施例２によるＷｅｂサービスシステムの基本的な構成は図１に示した実施例１のものと同様である。実施例２のＡＰＩゲートウェイ１００−２は、図１に括弧を用いて示したように、実施例１における第２変換部１３０が第２変換部１３０−２となり、その内部で判定部１３１が判定部１３１−２となっている。
【００８６】
実施例２による判定部１３１−２が実行するＣｏｏｋｉｅ付与判定処理は実施例１のものと異なる。図８は、実施例２によるＣｏｏｋｉｅ付与判定処理のフローチャートである。
【００８７】
図８を参照すると、まず判定部１３１−２は比較処理に利用するための所定の比較ドメイン名を作成する（ステップＦ１６０）。このとき作成する初期の比較ドメイン名はマッシュアップ処理部１１０が作成したＨＴＴＰ要求の送信先サーバのドメイン名である。
【００８８】
次に、判定部１３１−２は、比較ドメイン名にハッシュ関数Ｈ１０を適用し、要約値を算出する（ステップＦ１００−２）。その後、判定部１３１−２は、実施例１と同様にステップＦ１１０およびステップＦ１２０を実行し、ステップＦ１３０の判定を行う。
【００８９】
ステップＦ１３０の判定にて比較符号がＣｏｏｋｉｅ名と後方一致しないとき（Ｆ１３０でＮｏ）、判定部１３１−２は、比較ドメイン名がサブドメインを含まないトップレベルドメインであるか否か判定する（ステップＦ１７０）。比較ドメイン名がトップレベルドメインであれば（Ｆ１７０でＹｅｓ）、判定部１３１−２は、当該ＣｏｏｋｉｅをＨＴＴＰ要求に付与しないと判定する（ステップＦ１５０）。一方、比較ドメインがトップレベルドメインでない場合（Ｆ１７０でＮｏ）、判定部１３１−２は、比較ドメイン名から最も階層が深いサブドメイン（最も左側のサブドメイン）を１つ取り除く（ステップＦ１８０）。例えば、比較ドメイン名が「www.example.com」である場合、サブドメイン「www」を取り除き、「example.com」とする。ステップＦ１８０の後、判定部１３１−２はステップＦ１００−２に戻りそれ以降の処理を継続する。
【００９０】
以上、本実施例によれば、識別情報は、サブドメインを含むドメイン名である。第２変換部１３０−２は、要求メッセージの送信先と一致するか否かの判定に、当該要求メッセージに付与されたＣｏｏｋｉｅ（第２Ｃｏｏｋｉｅ）に埋め込まれたｄｏｍａｉｎ名（識別情報）からサブドメインを取り除いた値を用いる。Ｃｏｏｋｉｅの指定元がサブドメインを含むドメイン名を識別情報として示されていても要求メッセージの送信元との一致を判定できるので、サブドメイン間でのＣｏｏｋｉｅの共有が可能となる。
【００９１】
また、本実施例によれば、識別情報は、１つ以上のサブドメインを含むことが可能なドメイン名である。第２変換部１３０−２は、要求メッセージの送信先と、当該要求メッセージのＣｏｏｋｉｅ（第２Ｃｏｏｋｉｅ）に埋め込まれたドメイン名が示すサーバ３００とが一致するか否かの第１判定を行い、一致すれば、当該サーバ３００に第２Ｃｏｏｋｉｅから復元した第１Ｃｏｏｋｉｅを付与した要求メッセージを送信し、一致しなければ、ドメイン名がトップレベルドメインを示しているか否かの第２判定を行い、ドメイン名がトップレベルドメインを示していなければ、当該ドメイン名からサブドメインを１つ取り除いて第１判定に戻り、トップレベルドメインを示していれば、その送信先に、第２Ｃｏｏｋｉｅを削除した要求メッセージを送信する。複数のサブドメインを含むことが可能なドメイン名からサブドメインを順次取り除いていくことで、要求メッセージの送信先とＣｏｏｋｉｅの指定元とが一致するか否かを判定することができる。
【００９２】
本実施例によれば、Ｓｅｔ−Ｃｏｏｋｉｅヘッダのｄｏｍａｉｎ属性値がサーバのドメインよりも階層が浅い場合であっても、判定部１３１−２は、サーバ３００に対してＣｏｏｋｉｅを付与するか否かを正しく判定できる。これにより、サーバ３００ではＳｅｔ−Ｃｏｏｋｉｅヘッダのｄｏｍａｉｎ属性値に自身のドメイン名より階層の浅いドメイン名を指定することができ、異なるサブドメイン間のサーバ３００でＣｏｏｋｉｅを共有することができる。
【実施例３】
【００９３】
実施例１は、ＡＰＩゲートウェイ１００でマッシュアップされる複数のサーバ３００間でＣｏｏｋｉｅを分離し、Ｃｏｏｋｉｅの有効範囲をドメインに限定することを可能にする例を示した。実施例３では、サーバ３００のドメイン名に加えて、パスも利用してＣｏｏｋｉｅを分離することにより、Ｃｏｏｋｉｅの有効範囲をドメインの特定のパスに限定することを可能にする例を示す。サーバがＣｏｏｋｉｅの有効範囲としてドメインだけでなく、パスも利用して指定する場合に、ＡＰＩゲートウェイは、パスの指定を反映してＨＴＴＰ要求にＣｏｏｋｉｅを付与するか否かを判定することができる。
【００９４】
実施例３によるＷｅｂサービスシステムの基本的な構成は図１に示した実施例１のものと同様である。実施例３のＡＰＩゲートウェイ１００−３は、図１に括弧を用いて示したように、実施例１における、第１変換部１４０が第１変換部１４０−３となり、第２変換部１３０が第２変換部１３０−３となり、その内部で判定部１３１が判定部１３１−３となっている。
【００９５】
第１変換部１４０−３は、Ｓｅｔ−Ｃｏｏｋｉｅヘッダにｐａｔｈ属性が設定されている場合、ＨＴＴＰ応答の送信元サーバのドメイン名とＳｅｔ−Ｃｏｏｋｉｅヘッダのｐａｔｈ属性値とを結合した文字列を作成し、その文字列にハッシュ関数Ｈ１０を適用することにより要約値を算出する。また、第１変換部１４０−３は、Ｓｅｔ−Ｃｏｏｋｉｅヘッダにｐａｔｈ属性が設定されていない場合、ＨＴＴＰ応答の送信元サーバのドメイン名にハッシュ関数Ｈ１０を適用することにより要約値を算出する。
【００９６】
判定部１３１−３は、まず、ＨＴＴＰ要求の送信先サーバのドメイン名とＨＴＴＰ要求のパスとを結合した文字列に基づく比較符号についてＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名と後方一致を判断し、後方一致しない場合には実施例１と同様にＨＴＴＰ要求の送信先サーバのドメイン名に基づく比較符号についてＣｏｏｋｉｅヘッダのＣｏｏｋｉｅ名と後方一致を判断する。いずれかの比較符号がＣｏｏｋｉｅ名と後方一致すれば、判定部１３１−３は、当該Ｃｏｏｋｉｅヘッダを、当該送信先サーバに送信するＨＴＴＰ要求に付与すると決定する。
【００９７】
上述のように、実施例３による第１変換部１４０−３が実行するＳｅｔ−Ｃｏｏｋｉｅ変換処理は、図５に示した実施例１のものとは要約値の算出方法が異なる。図９は、実施例３によるＳｅｔ−Ｃｏｏｋｉｅ変換処理のフローチャートである。実施例３では、第１変換部１４０−３は、図５におけるステップＦ２００の代わりにステップＦ３００を実行する。それ以降のステップＦ２１０〜Ｆ２５０は実施例１のものと同じである。
【００９８】
ステップＦ３００において、まず、第１変換部１４０−３は、ＨＴＴＰ応答に付加されているＳｅｔ−Ｃｏｏｋｉｅヘッダにｐａｔｈ属性の要素が存在するか否か判定する（ステップＦ３１０）。Ｓｅｔ−Ｃｏｏｋｉｅヘッダにｐａｔｈ属性の要素が存在すれば（Ｆ３１０のＹｅｓ）、第１変換部１４０−３は、ＨＴＴＰ応答の送信元サーバのドメイン名とＳｅｔ−Ｃｏｏｋｉｅヘッダのｐａｔｈ属性値とを結合した文字列を作成し、その文字列にハッシュ関数Ｈ１０を適用することにより要約値を算出する（ステップＦ３２０）。一方、Ｓｅｔ−Ｃｏｏｋｉｅヘッダにｐａｔｈ属性の要素が存在しなれば（Ｆ３１０のＮｏ）、実施例１と同様に、第１変換部１４０−３は、ＨＴＴＰ応答の送信元サーバのドメイン名にハッシュ関数Ｈ１０を適用することにより要約値を算出する（ステップＦ２００）。
【００９９】
実施例３による判定部１３１−３が実行するＣｏｏｋｉｅ付与判定処理は実施例１のものと異なる。図１０は、実施例３によるＣｏｏｋｉｅ付与判定処理のフローチャートである。
【０１００】
図１０を参照すると、まず判定部１３１−３は比較処理に利用するための所定の比較情報を作成する（ステップＦ１９０）。このとき作成する初期の比較情報はマッシュアップ処理部１１０が作成したＨＴＴＰ要求の送信先サーバのドメイン名とＨＴＴＰ要求のパスとを結合した文字列である。
【０１０１】
次に、判定部１３１−３は、比較情報にハッシュ関数Ｈ１０を適用し、要約値を算出する（ステップＦ１００−３）。その後、判定部１３１−３は、実施例１と同様にステップＦ１１０およびステップＦ１２０を実行し、ステップＦ１３０の判定を行う。
【０１０２】
ステップＦ１３０の判定にて比較符号がＣｏｏｋｉｅ名と後方一致しないとき（Ｆ１３０でＮｏ）、判定部１３１−３は、図６のステップＦ１００に移行し、それ以降は図６に示した一連の処理を実行する。
【０１０３】
以上、本実施例によれば、第１変換部１４０−３は、ＨＴＴＰ応答に付加された第１Ｃｏｏｋｉｅがパス属性の要素を含んでいれば送信元サーバ３００のドメイン名とパス属性を含む文字列にハッシュ関数を適用して得た要約値にに基づく追記符号を、第１Ｃｏｏｋｉｅがパス属性の要素を含んでいなければ送信元サーバ３００のドメイン名にハッシュ関数を適用して得た要約値に基づく追記符号を、第１Ｃｏｏｋｉｅに追記して第２Ｃｏｏｋｉｅを生成する。第２変換部１３０−３は、クライアント２００からのＨＴＴＰ要求（要求メッセージ）の送信先サーバ３００のドメイン名と要求メッセージのパスとを含む文字列にハッシュ関数を適応して得た要約値またはドメイン名にハッシュ関数を適用して得た要約値のいずれかに基づく比較符号が、要求メッセージに付与された第２Ｃｏｏｋｉｅに含まれている追記符号と一致すれば、第２Ｃｏｏｋｉｅから追記符号を削除した第１Ｃｏｏｋｉｅを第２Ｃｏｏｋｉｅの代わりに付与した要求メッセージを送信先サーバ３００に送信し、いずれも一致しなければ、第２Ｃｏｏｋｉｅを削除した要求メッセージを送信先サーバ３００に送信する。サーバ３００のドメイン名とパスを含む要約値で要求メッセージの送信先と第１Ｃｏｏｋｉｅの発行元との一致を判定することができるので、サーバ３００が第１Ｃｏｏｋｉｅにてパス属性を指定して第１Ｃｏｏｋｉｅの有効範囲を所定のパスに限定することができる。
【０１０４】
本実施例によれば、サーバがＳｅｔ−Ｃｏｏｋｉｅヘッダにｐａｔｈ属性を指定する場合であっても、判定部１３１−３は、サーバ３００に対してＣｏｏｋｉｅヘッダを付与するか否かを正しく判定できる。これにより、サーバ３００ではＣｏｏｋｉｅの有効範囲を特定のパスに限定することができる。
【０１０５】
上述した本発明の各実施例は、本発明の説明のための例示であり、本発明の範囲をそれらの実施例のみに限定する趣旨ではない。当業者は、本発明の範囲を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【符号の説明】
【０１０６】
１００…ＡＰＩゲートウェイ、１１０…マッシュアップ処理部、１２０…記憶部、１３０…第１変換部、１３１…判定部、１３２…復元部、１４０…変換部、２００…クライアント、３００…サーバ、Ｈ２０１…プロセッサ、Ｈ２０２…メモリ装置、Ｈ２０３…入力装置、Ｈ２０４…ディスク装置、Ｈ２０５…通信制御装置、Ｈ２０６…内部通信線、Ｈ２０７…外部通信回線、Ｎ１０…通信ネットワーク、Ｎ２０…通信ネットワーク
【図１】
2019074835.tif 000003
【図２】
2019074835.tif 000004
【図３】
2019074835.tif 000005
【図４】
2019074835.tif 000006
【図５】
2019074835.tif 000007
【図６】
2019074835.tif 000008
【図７】
2019074835.tif 000009
【図８】
2019074835.tif 000010
【図９】
2019074835.tif 000011
【図１０】
2019074835.tif 000012