JP2016038750A

JP2016038750A - 情報処理装置およびその方法、並びに、情報処理システム

Info

Publication number: JP2016038750A
Application number: JP2014161894A
Authority: JP
Inventors: 鈴木　智也; Tomoya Suzuki; 智也鈴木
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-08-07
Filing date: 2014-08-07
Publication date: 2016-03-22
Also published as: US20160044140A1; US9648145B2

Abstract

【課題】メッセージを圧縮するテーブルの作成機能の整合性を判定する。【解決手段】ヘッダテーブル作成部310は、通信相手に送信するメッセージを圧縮し、通信相手から受信したメッセージを展開するためのテーブルを作成する。ヘッダテーブル更新部311は、送信するメッセージおよび受信したメッセージに基づきテーブルを更新する。テーブルを作成および更新するテーブル作成機能の整合性を判定する整合性確認部312は、通信相手に所定のメッセージを送信し、通信相手から受信した所定のメッセージに基づくリクエストメッセージによって、通信相手のテーブル作成機能と自装置のテーブル作成機能の間の整合性を判定する。【選択図】図2

Description

本発明は、メッセージ通信に関する。

インターネット標準技術として一般に広く利用されているプロトコルの一つにHTTP (hypertext transfer protocol)がある。現在、インターネット標準化団体であるIETF (The Internet Engineering Task Force)において、HTTPの新バージョンHTTP/2の標準化策定が進められている（非特許文献1参照）。

HTTP/2の新しい機能として、HTTPヘッダ圧縮機能がある。HTTPヘッダ圧縮機能は、HTTPヘッダテーブルと呼ばれる一種の辞書を利用してHTTPヘッダ情報をデータ圧縮し、サーバとクライアントの間においてHTTPヘッダ情報の差分のみを送受信する（非特許文献2参照）。これにより、サーバとクライアントの間で送受信されるHTTP通信メッセージのデータサイズが削減される。

しかし、HTTPヘッダ圧縮機能において、HTTPヘッダテーブルの作成は装置の実装に依存し、通信装置間でHTTPヘッダテーブルの整合性がとれなくなると、通信エラーが発生する可能性がある。従って、各装置のHTTPヘッダテーブルを作成する機能の整合性を確認する手段が望まれる。

http://www.ietf.org/id/draft-ietf-httpbis-http2-13.txt (2014.6.17) http://www.ietf.org/id/draft-ietf-httpbis-header-compression-08.txt (2014.6.17)

本発明は、メッセージを圧縮するテーブルの作成機能の整合性を判定することを目的とする。

本発明は、前記の目的を達成する一手段として、以下の構成を備える。

本発明にかかる情報処理装置は、通信相手に送信するメッセージを圧縮し、前記通信相手から受信したメッセージを展開するためのテーブルを作成する作成手段と、前記送信するメッセージおよび前記受信したメッセージに基づき前記テーブルを更新する更新手段と、前記テーブルを作成および更新するテーブル作成機能の整合性を判定する判定手段とを有し、前記判定手段は、前記通信相手に所定のメッセージを送信し、前記通信相手から受信した前記所定のメッセージに基づくリクエストメッセージによって、前記通信相手のテーブル作成機能と自装置のテーブル作成機能の間の整合性を判定する。

本発明によれば、メッセージを圧縮するテーブルの作成機能の整合性を判定することができる。

実施例の情報処理システムの構成例を示すブロック図。通信装置の機能構成例を示す図。 HTTPヘッダテーブルの構成例を説明する図。通信装置の間の通信シーケンスの概要を説明するシーケンス図。 HTTP通信接続の確立を説明するシーケンス図。リクエストとダミーレスポンスの送受信を説明するシーケンス図。ヘッダテーブル作成機能の整合性の確認を説明するシーケンス図。確認結果に基づくレスポンスの送信を説明するシーケンス図。 HTTP/2によるHTTP通信を説明するシーケンス図。 HTTP通信接続の切断を説明するシーケンス図。エラー通知受信時の通信装置の処理を説明するフローチャート。ヘッダテーブル作成機能の整合性を確認する処理例を説明するフローチャート。ヘッダテーブル作成機能の整合性を確認する別の処理例を説明するフローチャート。通信装置がリクエストを送信しレスポンスを受信する手順を説明するフローチャート。通信装置がリクエストを受信しレスポンスを送信する手順を説明するフローチャート。初期のHTTPヘッダテーブルの例を示す図。ダミーレスポンスのHTMLファイルに記載されるHTTP/2方式によるリクエスト例を示す図。図17に示すリクエストが送受信される際の通信装置のReqテーブルの更新状態例を示す図。ヘッダテーブル作成機能の整合性を確認するための検証用ペアのテーブル例を示す図。実施例2における通信装置の間の通信シーケンスの概要を説明するシーケンス図。リクエスト構文エラーを検知した場合にヘッダテーブル作成機能の整合性の確認が必要と判断する手順を示すフローチャート。

以下、本発明にかかる実施例の情報処理装置および情報処理方法を図面を参照して詳細に説明する。なお、実施例は特許請求の範囲にかかる本発明を限定するものではなく、また、実施例において説明する構成の組み合わせのすべてが本発明の解決手段に必須とは限らない。

［装置の構成］
図1のブロック図により実施例の情報処理システムの構成例を示す。通信装置10は、例えばIEEE802.11に準拠する無線ネットワーク通信機能を有する。通信装置10の通信相手である通信装置20は、通信装置10と同様の機能と構成を有し、ネットワーク30を介して通信装置10に接続し、情報処理システムを形成する。

通信装置10、20は、例えば、ディジタルカメラ、ディジタルビデオカメラ、携帯電話、スマートフォン、タブレットデバイス、パーソナルコンピュータ、サーバ装置などの情報処理装置である。なお、通信装置10、20の無線ネットワーク通信機能としてWi-Fi（商標）、Bluetooth（登録商標）、ZigBee（登録商標）、RFIDなどを用いてもよい。また、無線ネットワークに限らず、有線ネットワーク通信、または、無線ネットワーク通信と有線ネットワーク通信の組み合せを利用してもよい。

以下では、通信装置10と通信装置20が、直接、無線ネットワーク接続を行う例を説明するが、無線アクセスポイントを経由する接続を行ってもよい。無線ネットワーク接続後、通信装置10と通信装置20はHTTP/2に従い通信を行う。また、以下では、通信装置10の構成例を説明するが、通信装置20も同様の構成であり、通信装置20の構成の説明を省略する。また、二台の通信装置10と通信装置20が通信を行う例を示すが、通信装置は少なくとも二台であればよく、通信を行う通信装置の数に制限はない。

CPU201は、RAM203をワークメモリとして、ROMや記憶装置204に格納された各種プログラムを実行し、システムバス209を介して後述する構成を制御して、後述する通信機能を実現する。記憶装置204は、HDD、SDDまたはフラッシュメモリなど記録媒体であり、OSなどのプログラムのほかに、画像コンテンツや映像コンテンツなどデータを記憶する。

CPU201は、ユーザが通信装置10を操作するためのグラフィカルユーザインタフェイス(GUI)を表示部205に表示する。CPU201は、GUIに対するユーザ指示を操作部206を介して取得する。CPU201は、通信部207を制御して、ネットワーク30に接続したり、あるいは、通信装置20に直接ネットワーク接続したりする。

表示部205は、LCDなどの表示デバイスである。操作部206は、キーボード、ポインティングデバイス、各種ボタン、ダイヤル、または、タッチパネルである。操作部206（またはその一部）としてタッチパネルを使用する場合、タッチパネルと表示部205のLCDは一体に構成される。

［機能構成］
図2により通信装置20の機能構成例を示す。図2はサーバ装置の場合の機能構成を示し、通信装置10などのクライアント装置（以下、クライアント）の機能構成は図2に示す構成から整合性確認部312を除いた構成になる。

制御部301は、通信装置20が備える機能モジュール全体を制御する。通信制御部302は、通信部207を制御して、例えば通信装置10との間で無線ネットワーク通信方式の通信制御を行う。表示制御部303は、表示部205を制御して、通信装置20におけるGUIの表示制御を行う。

操作制御部304は、操作部206を制御して、通信装置20におけるユーザの操作入力制御を行う。記憶制御部305は、RAM203または記憶装置204を制御して、処理データ、または、画像コンテンツや映像コンテンツなどのデータの格納や削除を行う。

TCP/IP通信制御部306は、通信制御部302を利用して、クライアントとの間でTCP/IP (transmission Control Protocol/Internet protocol)方式の通信制御を行う。なお、TCP/IP通信制御部306は、TCP/IP通信に限らず、UDP (user datagram protocol)を利用する方式の通信制御も行う。

HTTP通信制御部307は、TCP/IP通信制御部306を利用して、クライアントとの間で、HTTP/2方式の通信制御を行う。また、HTTP通信制御部307は、通信装置20との間でTLS (transport layer security)を利用したHTTPS (HTTP security)方式の通信制御も行う。

サービス制御部308は、HTTP通信制御部307を利用して、クライアントに対するサービスの提供、または、クライアントが提供するサービスの利用を制御する。本実施例において、サービス制御部308は、DLNA (Digital living Network Alliance)、UPnP (universal plug and play)、および、ウェブ(Web)サービス方式を利用する。なお、サービス方式はこれらに限らず、SOAP (simple object access protocol）、REST (representational state transfer)、AtomPub (atom publishing protocol)など、他のサービス方式が利用されてもよい。

ヘッダ圧縮部309は、HTTPヘッダテーブルに基づき、HTTP/2におけるHTTPヘッダの圧縮処理/展開処理を行う。クライアントのヘッダ圧縮部309は、HTTP通信制御部307が作成したHTTPリクエストメッセージ中のHTTPヘッダ（以下、HTTPリクエストヘッダ）を圧縮する。また、クライアントのヘッダ圧縮部309は、HTTP通信制御部307が通信装置20から受信したHTTPレスポンスメッセージ中の圧縮されたHTTPヘッダを展開する。なお、以下ではHTTPリクエストメッセージを「リクエスト」、HTTPレスポンスメッセージを「レスポンス」と呼ぶ場合がある。

一方、サーバ装置である通信装置20のヘッダ圧縮部309は、HTTP通信制御部307が作成したレスポンス中のHTTPヘッダ（以下、HTTPレスポンスヘッダ）を圧縮する。また、通信装置20のヘッダ圧縮部309は、HTTP通信制御部307が通信装置10から受信したリクエスト中の圧縮されたHTTPリクエストヘッダを展開する。

ヘッダテーブル作成部310は、HTTP/2において規定された初期のHTTPヘッダテーブルを作成する。本実施例における初期のHTTPヘッダテーブルの具体例は後述する。ヘッダテーブル更新部311は、ヘッダ圧縮部309とHTTP通信制御部307により、圧縮されて送信されたHTTPリクエストヘッダに基づき、HTTPヘッダテーブルを更新する。また、HTTP通信制御部307とヘッダ圧縮部309により、受信され展開されたHTTPレスポンスヘッダに基づき、HTTPヘッダテーブルを更新する。

整合性確認部312は、クライアントのヘッダ圧縮部309、ヘッダテーブル作成部310およびヘッダテーブル更新部311の機能（以下、ヘッダテーブル作成機能）と、通信装置20のヘッダテーブル作成機能の間の整合性を確認する。

●HTTPヘッダテーブル
図3によりHTTPヘッダテーブルの構成例を説明する。HTTPヘッダテーブル400は、HTTPヘッダの圧縮および展開処理に利用されるHTTPリクエストヘッダテーブル410と、同様の処理に利用されるHTTPレスポンスヘッダテーブル420を有する。以下では、HTTPリクエストヘッダテーブルを「Reqテーブル」、HTTPレスポンスヘッダテーブルを「Resテーブル」と記載する。

Reqテーブル410は、当該テーブル中のレコード番号を示すインデクス411、リクエストヘッダ名412、リクエストヘッダ値413から構成される。同様に、Resテーブル420は、当該テーブル中のレコード番号を示すインデクス421、レスポンスヘッダ名422、レスポンスヘッダ値423から構成される。

［通信シーケンス］
図4のシーケンス図により通信装置10と通信装置20の間の通信シーケンスの概要を説明する。図4は、ネットワーク接続後、通信装置10と通信装置20が通信を開始して通信を切断するまでの通信シーケンスの概要を示す。

通信装置10と通信装置20は、HTTP通信接続の確立(S11)を行う。HTTP通信接続が確立すると、通信装置10はリクエストを送信し、当該HTTPレクエストに対して、通信装置20は、ヘッダテーブル作成機能の整合性を確認するためのダミーレスポンスを送信する(S12)。なお、ダミーレスポンスの詳細は後述する。

次に、通信装置10は、受信したダミーレスポンスに含まれるHTMLファイルに基づき、HTTP/2によるリクエストを行い、通信装置20は、受信したリクエストによってヘッダテーブル作成機能の整合性を確認する(S13)。そして、通信装置20は、整合性の確認結果に基づき、ステップS13で受信したリクエストに対するレスポンスを通信装置10に送信する(S14)。

次に、通信装置10と通信装置20は、HTTP/2によるHTTP通信（リクエストの送受信およびレスポンスの送受信）を行い(S15)、その後、通信装置10と通信装置20は、HTTP通信接続を切断する(S16)。ただし、ステップS15におけるHTTP/2によるHTTP通信は、ステップS13においてヘッダテーブル作成機能の整合性がとれていると判定された場合に行われる。

このように、通信装置20は、通信装置10との間のHTTP通信開始時に、通信装置10のヘッダテーブル作成機能と自装置の当該機能との間の整合性を確認し、整合性の確認結果に基づき、HTTP/2によるHTTP通信が可能か否かを判定する。なお、図4には示さないが、HTTP/2によるHTTP通信が不可能と判定された場合、例えば、通信装置10と通信装置20はHTTP/1.1によるHTTP通信に移行することができる。

●HTTP通信接続の確立(S11)
図5のシーケンス図によりHTTP通信接続の確立(S11)を説明する。通信装置10と通信装置20の間のTCPセッションの確立(S11A)が行われる。通信装置10が通信装置20にTCP接続要求（SYNフレーム）を送信し(S111)、通信装置20が通信装置10にTCP接続要求応答（SYN/ACKフレーム）を送信する(S112)。そして、通信装置10が通信装置20に応答（ACKフレーム）を送信して(S113)、TCPセッションが確立する。

次に、通信装置10と通信装置20の間のTLSセッションの確立(S11B)が行われる。通信装置10が通信装置20に利用可能な暗号化、圧縮アルゴリズムの一覧(Client Hello)を送信する(S114)。次に、通信装置20が通信装置10に決定した暗号化、圧縮アルゴリズムの情報(Server Hello)を送信する(S115)。

さらに、通信装置20が通信装置10にルート証明書、サーバ証明書(Server Certificate)を送信する(S116)。通信装置20が通信装置10にサーバ鍵情報(Server Key Exchange)を送信する(S117)。そして、通信装置20が通信装置10に一連の処理の完了メッセージ(Server Hello Done)を送信する(S118)。

次に、通信装置10が通信装置20に鍵情報（プリマスタシークレット）(Client Key Exchange)を送信する(S119)。通信装置10が通信装置20に暗号化アルゴリズムの準備完了メッセージ(Change Cipher Spec)を送信する(S120)。そして、通信装置10が通信装置20に鍵交換と認証処理の完了メッセージ(Finished)を送信する(S121)。

次に、通信装置20が通信装置10に暗号化アルゴリズムの準備完了メッセージ(Change Cipher Spec)を送信する(S122)。そして、通信装置20が通信装置10に鍵交換と認証処理の成功メッセージ(Finished)を送信して(S123)、TLSセッションが確立する。このようにして、TCPセッションとTLSセッションが確立した後、HTTP通信接続を行う。

●リクエストとダミーレスポンスの送受信(S12)
図6のシーケンス図によりリクエストとダミーレスポンスの送受信(S12)を説明する。通信装置10は、新規のHTTPヘッダテーブル400を作成し(S131)、リクエストを作成し、Reqテーブル410を利用してHTTPリクエストヘッダを圧縮する(S132)。そして、通信装置10は、作成したHTTPリクエストヘッダに基づき、Reqテーブル410を更新する(S133)。

次に、通信装置10は、HTTP/2によりリクエストを通信装置20に送信する(S134)。リクエストの送信(S134)は、次のフレームの送信から構成される。
S134a：HTTPリクエストラインとHTTPリクエストヘッダを示すHEADERS＋0個以上のCONTINUATIONフレームの送信、
S134b：リクエストボディを示すDATAフレームの送信、
S134c：END_STREAMフラグを付与した最終DATAフレームの送信

リクエストを受信した通信装置20は、新規にHTTPヘッダテーブル400を作成し(S135)、受信したリクエストのHTTPリクエストヘッダに基づき、Reqテーブル410を更新する(S136)。そして、通信装置20は、受信したリクエストに対してダミーレスポンスを作成し、Resテーブル420を利用してHTTPレスポンスヘッダを圧縮する(S137)。そして、通信装置20は、作成したHTTPレスポンスヘッダに基づき、Resテーブル420を更新する(S138)。

通信装置20は、通信装置10からリクエストを初めて受信した場合、または、通信装置10のリクエストから構文エラーを検出した場合、ダミーレスポンスを作成する。ヘッダテーブル作成機能の整合性を確認するためダミーレスポンスには、通信装置10に新規のHTTP通信を開始させた上、通信装置10に送信させる複数のリクエストを記載したHTMLファイルが含まれる。

詳細は後述するが、当該リクエストには、ヘッダテーブル作成機能の整合性を確認するためのリクエストであることを通信装置20が判別するための情報が含まれる。以下では、ヘッダテーブル作成機能の整合性を確認するためのリクエストであることを示す情報を含むリクエストを「整合性確認リクエスト」と呼ぶ場合がある。

次に、通信装置20は、HTTP/2によりダミーレスポンスを通信装置10に送信する(S139)。ダミーレスポンスの送信(S139)は、次のフレームの送信から構成される。
S139a：HTTPステータスラインとHTTPレスポンスヘッダを示すHEADERSフレームの送信、
S139b：ダミーレスポンスボディを示すDATAフレームの送信、
S139c：END_STREAMフラグを付与した最終DATAフレームの送信

ダミーレスポンスを受信した通信装置10は、ダミーレスポンスのHTTPレスポンスヘッダに基づき、Resテーブル420を更新する(S140)。

●ヘッダテーブル作成機能の整合性の確認(S13)
図7のシーケンス図によりヘッダテーブル作成機能の整合性の確認(S13)を説明する。通信装置10は、ダミーレスポンスに含まれるHTMLファイルに従い、新規のHTTP通信を開始してリクエストを送信するために、通信装置20との間に新規のHTTP通信接続を確立する(S141)。そして、通信装置10は、新規のHTTPヘッダテーブル400を作成する(S142)。

次に、ダミーレスポンスに含まれるHTMLファイルに記載されたすべてのリクエストを通信装置10が送信するまで以下の処理が繰り返される。通信装置10は、ダミーレスポンスに含まれるHTMLファイルに記載されたリクエストを一行分読み取る(S143)。通信装置10は、読み取ったリクエストから通信装置20に送信するリクエスト（整合性確認リクエスト）を生成し、Reqテーブル410を利用してHTTPリクエストヘッダを圧縮する(S144)。

次に、通信装置10は、作成したHTTPリクエストヘッダに基づき、Reqテーブル410を更新する(S145)。そして、HTTP/2によりリクエストを通信装置20に送信する(S146)。リクエストの送信(S146)は、図6に示したステップS136の処理と同様であり、詳細説明を省略する。

リクエストを受信した通信装置20は、HTTPヘッダテーブル400が存在しない新規のHTTP通信の開始時は新規のHTTPヘッダテーブル400を作成する(S147)。そして、通信装置20は、受信したリクエストのHTTPリクエストヘッダに基づき、Reqテーブル410を更新する(S148)。

この場合、通信装置20が受信するリクエストは整合性確認リクエストであり、通信装置20は、更新したReqテーブル410の構成から、通信装置10のヘッダテーブル作成機能と、通信装置20の当該機能の整合性を確認する(S149)。整合性の確認の詳細は後述する。

次に、通信装置20は、受信した整合性確認リクエストに対して正常処理を示す既定のレスポンスを作成し、Resテーブル420を利用してHTTPレスポンスヘッダを圧縮する(S150)。そして、通信装置20は、作成したHTTPレスポンスヘッダに基づき、Resテーブル420を更新する(S151)。そして、HTTP/2によりレスポンスを通信装置10に送信する(S152)。レスポンスの送信(S152)は、図6に示したステップS139の処理と同様であり、詳細説明を省略する。

レスポンスを受信した通信装置10は、レスポンスのレスポンスヘッダに基づき、Resテーブル420を更新する(S152)。そして、ダミーレスポンスに含まれるHTMLファイルに記載されたすべてのリクエストを送信したか否かを判定し(S153)、未送信のリクエストがある場合は処理をステップS143に戻す。また、すべてのリクエストの送信が完了した場合は、ステップS141で確立した通信装置20との間のHTTP通信接続を切断する(S154)。

●確認結果に基づくレスポンスの送信(S14)
図8のシーケンス図により確認結果に基づくレスポンスの送信(S14)を説明する。通信装置20は、通信装置10のヘッダテーブル作成機能と通信装置20の当該機構の整合性を確認して、整合性があると判定した場合はステップS14Aを実行し、整合性がないと判定した場合は処理ステップS14Bを実行する。

整合性があると判定した場合(S14A)、通信装置20は、ステップS146において受信したリクエストに対応するレスポンスを作成し、Resテーブル420を利用してHTTPレスポンスヘッダを圧縮する(S161)。そして、通信装置20は、作成したHTTPレスポンスヘッダに基づき、Resテーブル420を更新する(S162)。ここで利用されるResテーブル420は、ステップS135で作成されたHTTPヘッダテーブル400のResテーブル420である。通信装置20は、HTTP/2によりレスポンスを通信装置10に送信する(S163)。レスポンスの送信(S163)は、図6に示したステップS139の処理と同様であり、詳細説明を省略する。

整合性がないと判定した場合(S14B)、通信装置20は、通信装置10に対してエラーを通知し、HTTP/2の通信を終了する。つまり、通信装置20は、HTTP/2のRST_STREAMフレームを通信装置10に送信し(S164)、HTTP/2のGOAWAYフレームを通信装置10に送信する(S165)。

●HTTP/2によるHTTP通信(S15)
図9のシーケンス図によりHTTP/2によるHTTP通信(S15)を説明する。通信装置10は、リクエストを作成し、Reqテーブル410を利用して、HTTPリクエストヘッダを圧縮する(S171)。そして、通信装置10は、作成したHTTPリクエストヘッダに基づき、Reqテーブル410を更新する(S172)。ここで利用されるReqテーブル410は、ステップS131で作成されたHTTPヘッダテーブル400のReqテーブル410である。通信装置10は、HTTP/2によりリクエストを通信装置20に送信する(S173)。リクエストの送信(S173)は、図6に示したステップS136の処理と同様であり、詳細説明を省略する。

リクエストを受信した通信装置20は、HTTPヘッダテーブル400が存在しない新規のHTTP通信の開始時は新規のHTTPヘッダテーブル400を作成する(S174)。通信装置20は、受信したリクエストのHTTPリクエストヘッダに基づき、Reqテーブル410を更新する(S175)。通信装置20は、受信したリクエストに対してレスポンスを作成し、Resテーブル420を利用してHTTPレスポンスヘッダを圧縮する(S176)。そして、通信装置20は、作成したHTTPレスポンスヘッダに基づき、Resテーブル420を更新する(S177)。

次に、通信装置20は、HTTP/2によりレスポンスを通信装置10に送信する(S178)。レスポンスの送信(S178)は、図6に示したステップS139の処理と同様であり、詳細説明を省略する。レスポンスを受信した通信装置10は、レスポンスのHTTPレスポンスヘッダに基づき、Resテーブル420を更新する(S179)。

●HTTP通信接続の切断(S16)
図10のシーケンス図によりHTTP通信接続の切断(S16)を説明する。通信装置10がHTTP/2におけるGOAWAYフレームを通信装置20に送信し(S181)、通信装置20との間のTCPセッションを切断するために通信装置10がTCP切断要求（FINフレーム）を通信装置20に送信する(S182)。TCP切断要求を受信した通信装置20がTCP切断要求応答（FIN/ACKフレーム）を通信装置10に送信し(S183)、通信装置10が応答（ACKフレーム）を通信装置20に送信する(S183)。以上で、HTTP通信接続が切断される。

●エラー通知受信時の処理
図11のフローチャートによりエラー通知受信時の通信装置10の処理を説明する。つまり、ヘッダテーブル作成機能の整合性がとれていないと判定された場合の通信装置10の処理を説明する。

前述したように、通信装置10のHTTP通信制御部307は、ダミーレスポンスに含まれるHTMLファイルに記載されたリクエストのすべてを送信する(S201)。そして、HTTP通信制御部307は、通信装置20からRST_STREAMフレームを受信したか否かを判定し(S202)、RST_STREAMフレームを受信した場合は処理をステップS204に進める。RST_STREAMフレームを未受信の場合、ヘッダテーブル作成機能の整合性がとれていてHTTP/2によるリクエストとレスポンスが正常に処理されていると判断し、HTTP/2によるHTTP通信を継続する(S203)。

RST_STREAMフレームを受信した場合、HTTP通信制御部307は、ヘッダテーブル作成機能の整合性がとれていないと判断して、HTTP/2のほかに対応可能なHTTPバージョンがあるか否かを判定する(S204)。通常、HTTP/1.1に対応可能であるから、HTTP通信制御部307は、HTTP/1.1によるHTTP通信を開始する(S206)。もし、他のバージョンがない場合、HTTP通信制御部307は、HTTP通信接続を切断する(S205)。

●ヘッダテーブル作成機能の整合性の確認
図12のフローチャートによりヘッダテーブル作成機能の整合性を確認する処理例を説明する。ここでは、Reqテーブル410の更新に、増加インデキシングのみを使用する例を説明する。通信装置20は、ダミーレスポンスに含まれるHTMLファイルに記載されたリクエストの数分、ステップS302からS311の処理を繰り返す。

HTTP通信制御部307は、通信装置10からHTTP/2によるリクエストを受信する(S302)。図15のフローチャートの一部を用いてリクエストの受信処理(S302)を説明する。HTTP通信制御部307は、HEADERS＋0個以上のCONTINUATIONフレームを受信したか否かを判定する(S601)。当該フレームが受信されると、ヘッダテーブル作成部310は、新規のHTTPヘッダテーブル400を作成する(S602)。

次に、ヘッダ圧縮部309は、受信したHEADERS＋0個以上のCONTINUATIONフレームに含まれる圧縮されたHTTPリクエストヘッダをReqテーブル420を利用して展開する(S603)。HTTP通信制御部307は、受信したリクエストにリクエストボディがあるか否かを判定する(S604)。

リクエストにリクエストボディがある場合、HTTP通信制御部307は、DATAフレームを受信する(S605)。このDATAフレームには、リクエストボディの情報が含まれる。そして、HTTP通信制御部307は、リクエストボディデータのサイズ分、DATAフレームの受信(S605)を繰り返す。

次に、整合性確認部312は、ステップS302において受信されたリクエスト（以下、受信リクエスト）がHTTPヘッダテーブルの更新に増加インデキシングを用いるか否かを判定する(S303)。そして、増加インデキシングを用いる場合は処理をステップS304に進め、増加インデキシングを用いない場合は処理をステップS307に進める。

増加インデキシングを用いる場合、ヘッダテーブル更新部311は、受信リクエストのHTTPリクエストヘッダの増加インデキシング指示に基づき、Reqテーブル410を更新する(S304)。整合性確認部312は、更新されたReqテーブル410のリクエストヘッダ名412とリクエストヘッダ値413のペアと、整合性を確認するために保持するリクエストヘッダ名とリクエストヘッダ値のペアを比較する(S305)。以下では、Reqテーブル410の上記ペアを「テーブルペア」、整合性を確認するため上記ペアを「検証用ペア」と呼ぶ場合がある。検証用ペアの詳細は後述する。

次に、整合性確認部312は、ステップS305の比較結果がテーブルペアと検証用ペアの合致を示すか否かを判定する(S306)。そして、合致を示す場合は処理をステップS307に進め、合致を示さない場合は処理をステップS310に進める。

増加インデキシングを用いない場合、または、テーブルペアと検証用ペアが合致する場合、整合性確認部312は、受信リクエストがHTTPヘッダテーブルのインデクス（以下、テーブルインデクス）を使用するか否かを判定する(S307)。そして、テーブルインデクスを使用する場合は処理をステップS308に進め、テーブルインデクスを使用しない場合は処理をステップS311に進める。

テーブルインデクスを使用する場合、HTTPヘッダ圧縮部309は、受信リクエストのHEADERS＋0個以上のCONTINUATIONフレームに含まれる圧縮されたHTTPリクエストヘッダをReqテーブル410を利用して展開する(S308)。整合性確認部312は、展開されたHTTPリクエストヘッダの構成と、ダミーレスポンスに含まれるHTMLファイルに記載されたリクエストが合致するか否かを判定する(S309)。そして、合致する場合は処理をステップS311に進め、合致しない場合は処理をステップS310に進める。

テーブルペアと検証用ペアが合致しない場合、または、ヘッダ構成とリクエストが合致しない場合、整合性確認部312は、通信装置10のヘッダテーブル作成機能と、通信装置20の当該機能に整合性がないと判定する(S310)。

次に、整合性確認部312は、受信リクエストに対して既定のレスポンスを送信する(S311)。図15のフローチャートの一部を用いてレスポンスの送信処理(S311)を説明する。HTTPヘッダ圧縮部309は、Resテーブル420を利用してHTTPレスポンスヘッダを圧縮する(S607)。HTTP通信制御部307は、圧縮されたHTTPレスポンスヘッダを含むレスポンスを作成し(S608)、HEADERSフレームを通信装置10に送信する(S609)。HEADERSフレームには、圧縮されたHTTPレスポンスヘッダの情報が含まれる。

次に、HTTP通信制御部307は、作成したレスポンスにレスポンスボディがあるか否かを判定する(S610)。レスポンスボディがある場合、HTTP通信制御部307は、DATAフレームを通信装置10に送信する(S611)。DATAフレームには、ステップS608において作成されたレスポンスボディの情報が含まれる。そして、HTTP通信制御部307は、レスポンスボディデータのサイズ分、DATAフレームの送信(S611)を繰り返し、最後のDATAフレームにEND_STREAMフラグを設定する。

なお、ステップS311において送信される既定のレスポンスは、ヘッダテーブル作成機能の確認用の既定のレスポンスである。ヘッダテーブル作成機能の確認は、Reqテーブル410を用いて行うため、Resテーブル420の利用は任意とする。

次に、整合性確認部312は、通信装置10のヘッダテーブル作成機能と、通信装置20の当該機能に整合性がないことを検出したか否かを判定する(S312)。そして、整合性がないことを検出した場合は処理をステップS313に進め、整合性があることを検出した場合は処理をステップS315に進める。

整合性がない場合、整合性確認部312は、HTTP通信制御部307により、HTTP/2による通信エラーを通信装置10に通知し(S313)、通信装置10との間のHTTP/2によるHTTP通信接続を切断する(S314)。

整合性がある場合、整合性確認部312は、HTTP通信制御部307により、ダミーレスポンスを送信した際に、通信装置20が通信装置10から受信(S146)したリクエストに対する正規のレスポンスを送信する(S315)。

図13のフローチャートによりヘッダテーブル作成機能の整合性を確認する別の処理例を説明する。図13において、図12に示した処理例と異なるのは、Reqテーブル410の更新に、増加インデキシングに加えて置換インデキシングを使用する点であり、この点に関する処理を除き図12と同様の符号を付して、説明を省略する。通信装置20は、ダミーレスポンスに含まれるHTMLファイルに記載されたリクエストの数分、ステップS302からS311の処理を繰り返す。

整合性確認部312は、受信リクエストがHTTPヘッダテーブルの更新に置換インデキシングを用いるか否かを判定する(S321)。そして、置換インデキシングを用いる場合は処理をステップS322に進め、置換インデキシングを用いない場合は処理をステップS307に進める。

置換インデキシングを用いる場合、ヘッダテーブル更新部311は、受信リクエストのHTTPリクエストヘッダの置換インデキシング指示に基づき、Reqテーブル410を更新する(S322)。整合性確認部312は、更新されたReqテーブル410のリクエストヘッダ名412とリクエストヘッダ値413のテーブルペアと、リクエストヘッダ名とリクエストヘッダ値の検証用ペアを比較する(S323)。

次に、整合性確認部312は、ステップS323の比較結果がテーブルペアと検証用ペアの合致を示すか否かを判定する(S324)。そして、合致を示す場合は処理をステップS307に進め、合致を示さない場合は処理をステップS310に進める。以降の処理は図12と同様である。

●リクエストの送信とレスポンスの受信
図14のフローチャートにより通信装置10がリクエストを送信しレスポンスを受信する手順を説明する。HTTPヘッダ圧縮部309は、HTTPヘッダテーブルを利用して、HTTPリクエストヘッダを圧縮する(S501)。

HTTP通信制御部307は、圧縮されたHTTPリクエストヘッダを含むリクエストを作成し(S502)、通信装置20にHEADERS＋0個以上のCONTINUATIONフレームを送信する(S503)。このフレームには、ステップS501において圧縮されたHTTPリクエストヘッダの情報が含まれる。

次に、HTTP通信制御部307は、作成したリクエスト中にリクエストボディがあるか否かを判定し(S504)、リクエストボディがある場合は通信装置20にDATAフレームを送信する(S505)。このフレームには、ステップS502において作成されたリクエストボディの情報が含まれる。HTTP通信制御部307は、リクエストボディデータのサイズ分、DATAフレームの送信を繰り返し、最後のDATAフレームにEND_STREAMフラグを設定する。

次に、HTTP通信制御部307は、通信装置20に対するリクエストの送信に成功したか否かを判定し(S506)、リクエストの送信に失敗した場合は通信装置20とのHTTP通信接続を切断して(S514)、処理を終了する。

リクエストの送信に成功した場合、HTTP通信制御部307は、通信装置20からレスポンスのHEADERSフレームを受信したか否かを判定する(S507)。所定時間経過してもHEADERSフレームが受信されない場合、HTTP通信制御部307は、通信装置20とのHTTP通信接続を切断して(S514)、処理を終了する。

HEADERSフレームが受信された場合、HTTPヘッダ圧縮部309は、受信したHEADERSフレームに含まれる圧縮されたHTTPレスポンスヘッダをHTTPヘッダテーブルを利用して展開する(S508)。HTTP通信制御部307は、受信するレスポンスにレスポンスボディがあるか否かを判定し(S509)、レスポンスボディがある場合は通信装置20からDATAフレームを受信する(S510)。このフレームには、レスポンスボディの情報が含まれる。HTTP通信制御部307は、レスポンスボディデータのサイズ分、DATAフレームの受信を繰り返す。

次に、HTTP通信制御部307は、通信装置20からのレスポンスの受信に成功したか否かを判定し(S511)、レスポンスの受信に失敗した場合は通信装置20とのHTTP通信接続を切断して(S514)、処理を終了する。

レスポンスの受信に成功した場合、ヘッダテーブル更新部311は、ステップS501とS502において作成されたHTTPリクエストヘッダに基づきReq410テーブルを更新する(S512)。さらに、ステップS1507において受信したHTTPレスポンスヘッダに基づきResテーブル420を更新し(S513)、処理が終了する。

●リクエストの受信とレスポンスの送信
図15のフローチャートにより通信装置20がリクエストを受信しレスポンスを送信する手順を説明する。HTTP通信制御部307は、リクエストのHEADERS＋0個以上のCONTINUATIONフレームを受信したか否かを判定する(S601)。所定時間経過してもHEADERS＋0個以上のCONTINUATIONフレームが受信されない場合、HTTP通信制御部307は、通信装置10とのHTTP通信接続を切断して(S615)、処理を終了する。

HEADERS＋0個以上のCONTINUATIONフレームが受信された場合、ヘッダテーブル作成部310は、新規のHTTPヘッダテーブルを作成する(S602)。HTTPヘッダ圧縮部309は、受信したHEADERS＋0個以上のCONTINUATIONフレームに含まれる圧縮されたHTTPリクエストヘッダをHTTPヘッダテーブルを利用して展開する(S603)。

次に、HTTP通信制御部307は、受信するリクエストにリクエストボディがあるか否かを判定し(S604)、リクエストボディがある場合は通信装置10からDATAフレームを受信する(S605)。このフレームには、リクエストボディの情報が含まれる。HTTP通信制御部307は、リクエストボディデータのサイズ分、DATAフレームの受信を繰り返す。

次に、HTTP通信制御部307は、通信装置10からのリクエストの受信に成功したか否かを判定し(S606)、リクエストの受信に失敗した場合は通信装置10とのHTTP通信接続を切断して(S615)、処理を終了する。

リクエストの受信に成功した場合、HTTPヘッダ圧縮部309は、HTTPヘッダテーブルを利用してHTTPレスポンスヘッダを圧縮する(S607)。HTTP通信制御部307は、圧縮されたHTTPレスポンスヘッダを含むレスポンスを作成し(S608)、通信装置10にHEADERSフレームを送信する(S609)。このフレームには、圧縮されたHTTPレスポンスヘッダの情報が含まれる。

次に、HTTP通信制御部307は、作成したレスポンス中にレスポンスボディがあるか否かを判定し(S610)、リクエストボディがある場合は通信装置10にDATAフレームを送信する(S611)。このフレームには、ステップS608において作成されたレスポンスボディの情報が含まれる。HTTP通信制御部307は、レスポンスボディデータのサイズ分、DATAフレームの送信を繰り返し、最後のDATAフレームにEND_STREAMフラグを設定する。

次に、HTTP通信制御部307は、通信装置10に対するレスポンスの送信に成功したか否かを判定し(S612)、レスポンスの送信に失敗した場合は通信装置10とのHTTP通信接続を切断して(S615)、処理を終了する。

レスポンスの送信に成功した場合、ヘッダテーブル更新部311は、ステップS601において受信されたHTTPリクエストヘッダに基づきReqテーブル410を更新する(S613)。さらに、ステップS607とS608において作成されたHTTPレスポンスヘッダに基づきResテーブル420を更新し(S614)、処理が終了する。

●初期のHTTPヘッダテーブル
図16により初期のHTTPヘッダテーブル400の例を示す。Reqテーブル410には、初期レコードとして、インデクス0番から37番までのHTTPリクエストヘッダ名およびHTTPリクエストヘッダ値が設定される。同様に、Resテーブル420には、初期レコードとして、インデクス0番から34番までのHTTPレスポンスヘッダ名およびHTTPレスポンスヘッダ値が設定される。

図17によりダミーレスポンスのHTMLファイルに記載されるHTTP/2方式によるリクエスト例を示す。通信装置10は、図17(a)から図17(d)のリクエストが昇順に記載されたHTMLファイルを受信し、図17(a)から図17(d)の記載順にリクエストを通信装置20に送信する。

図17(a)に示すリクエストと図17(b)に示すリクエストは同内容である。通信装置10は、図17(a)のリクエストを送信する際、HTTPヘッダテーブル400を作成し、増加インデキシングによりHTTPヘッダテーブル400を更新する。そして、図17(b)のリクエストを送信する際、図17(a)のリクエスト送信時に更新したHTTPヘッダテーブル400のインデクスを使用して、ヘッダ圧縮を実施する。

図17(c)に示すリクエストと図17(d)に示すリクエストは同内容である。通信装置10は、図17(c)のリクエストを送信する際、当該リクエストのヘッダ2031とヘッダ2032に関して、増加インデキシングまたは置換インデキシングによりHTTPヘッダテーブル400を更新する。そして、図17(d)のリクエストを送信する際、図17(c)のリクエスト送信時に更新したHTTPヘッダテーブル400のインデクスを使用して、ヘッダ圧縮を実施する。

通信装置20は、通信装置10から受信したリクエストについて、HTMLファイルに記載したHTTP/2方式によるリクエストとの整合性を確認して、ヘッダテーブル作成機能の整合性を確認する。通信装置20が確認する項目は以下の二点である。

第一の確認項目は、HTTPリクエストヘッダ名とHTTPリクエストヘッダ値の組み合わせである。通信装置10のリクエストに基づき作成、更新されたHTTPヘッダテーブル400におけるHTTPリクエストヘッダ名とHTTPリクエストヘッダ値の組み合わせが、HTMLファイルに記載したリクエストと整合するか否かが判定される。その際、検証用ペアのテーブルを用いて判定が行われる。

第二の確認項目は、HTTPリクエストヘッダ名とHTTPリクエストヘッダ値の組み合わせに付与されるインデクスの対応関係である。通信装置10からインデクスを使用したリクエストを受信すると、通信装置20が通信装置10のリクエストに基づき作成、更新したHTTPヘッダテーブル400に基づきHTTPリクエストヘッダが展開される。展開されたHTTPリクエストヘッダ名とHTTPリクエストヘッダ値の組み合わせが、HTMLファイルに記載したリクエストと整合するか否かが判定される。つまり、通信装置10のインデクス付与方法と、通信装置20のインデクス付与方法の整合が判定される。

図18により図17に示すリクエストが送受信される際の通信装置10のReqテーブルの更新状態例を示す。図18(a)のReqテーブル410aは、通信装置10が図18(a)に示すリクエスト送信時に更新したReqテーブル例を示す。Reqテーブル410aには、インデクス0番から37番までの初期レコードに加えて次のレコードが含まれる。
インデクス│HTTPリクエストヘッダ名│ ヘッダ値
─────┼───────────┼───────────
38 │ :path │/my-example/index.html
39 │ :user-agent │my-user-agent
40 │ :x-my-header │first
41 │ :x-my-header-2 │first-2

図18(b)のReqテーブル410bは、通信装置10が図17(c)に示すリクエストの送信時に更新したReqテーブル例を示す。Reqテーブル410bは、図18(a)に示すReqテーブル410aに対して、次のレコードが更新されている。
インデクス│HTTPリクエストヘッダ名│ ヘッダ値
─────┼───────────┼─────────────
38 │ :path │/my-example/resources/script.js
40 │ :x-my-header │second
41 │ :x-my-header-2 │first-3

図19によりヘッダテーブル作成機能の整合性を確認するための検証用ペアのテーブル例を示す。検証用ペアテーブルは、ダミーファイルに含まれるHTMLファイルに記載したリクエストに含まれるHTTPリクエストヘッダ名とHTTPリクエストヘッダ値の組み合わせのすべてを抽出したテーブルである。通信装置20は、通信装置10からリクエストを受信すると、当該リクエストに含まれるHTTPリクエストヘッダ名とHTTPリクエストヘッダ値（テーブルペア）と、図19に示すの検証用ペアを比較して、それらペアの整合性を確認する。

このように、通信装置20は、通信装置10から最初のリクエストを受信するとダミーレスポンスを送信し、通信装置10のヘッダテーブル作成機能と自身の当該機能の整合性を確認し、HTTPヘッダテーブルを使用するヘッダ圧縮の妥当性を判定する。これにより、HTTPヘッダテーブルの不整合に起因する通信エラーを検出することができ、信頼性の高い通信が可能になる。

また、図6に示すように、通信装置20は、通信装置10とHTTP通信接続シーケンスを終了し、通信装置10からリクエストを受信すると、ヘッダテーブル作成機能の確認のためのダミーレスポンスを送信する。そのため、図7に示すように、通信装置10は、受信したダミーレスポンスに含まれるHTMLファイルに記載されたリクエストを送信することになる。その結果、通信装置20は、通信装置10のヘッダテーブル作成機能と自身の当該機能の整合性を確認することが可能になる。これにより、HTTPヘッダテーブルの不整合に起因する通信エラーの発生を本通信を開始する前に検知することが可能になる。

また、図8に示すように、通信装置20は、通信装置10のヘッダテーブル作成機能と自身の当該機能に整合性があると判断した場合、ダミーレスポンスを送信したリクエストに対して正常なレスポンスを送信する。その結果、通信装置20は、通信装置10からの通常のリクエストに基づき、ヘッダテーブル作成機能の確認を本通信を開始する前に実施することが可能になる。これにより、通信装置10への整合性確認部312の搭載が不要になり、通信装置20への整合性確認部312の搭載のみにより、通信装置10のヘッダテーブル作成機能の確認が可能になる。

一方、図8に示すように、通信装置20は、通信装置10のヘッダテーブル作成機能と自身の当該機能に整合性がないと判断した場合、通信装置10にエラーを通知し、HTTP/2方式による通信を終了する。その結果、図11に示すように、通信装置10は、HTTP/2方式による通信が不可能と判断して、他の通信方式への切り替えが可能になる。これにより、HTTPヘッダテーブルの不整合に起因する通信エラーの発生を本通信を開始する前に検知することが可能になり、本通信における通信エラーにかかる処理負荷、通信遅延を軽減し、他の通信方式へのスムーズな切り替えを行うことができる。

［変形例］
上記では、整合性確認部312が、HTTP通信接続シーケンスが終了した後、ヘッダテーブル作成機能の整合性を判断したが、これに限らない。例えば、通信装置10が同一リクエストを繰り返し送信してくる場合など、通信装置10の動作に異常が認められる場合、整合性確認部312がヘッダテーブル作成機能の整合性を確認してもよい。また、HTTP通信制御部307を利用して、通信装置10のリクエストに構文エラーなどの異常を検出した際、整合性確認部312がヘッダテーブル作成機能を確認することもできる（この例は、実施例2において説明する）。

以下、本発明にかかる実施例2の情報処理装置および情報処理方法を説明する。なお、実施例2において、実施例1と略同様の構成については、同一の符号を付して、その詳細な説明を省略する場合がある。

図20のシーケンス図により実施例2における通信装置10と通信装置20の間の通信シーケンスの概要を説明する。図20は、ネットワーク接続後、通信装置10と通信装置20が通信を開始して通信を切断するまでの通信シーケンスの概要を示す。

実施例2において、HTTP通信接続の確立(S11)後、通信装置20は、通信装置10との通信（リクエスト・レスポンスの送受信）を行う(S21)。そして、通信中に発生するリクエスト構文エラーを検知すると(S22)、ヘッダテーブル作成機能の整合性の確認(S13)に基づき、HTTP/2方式によるHTTP通信の継続が可能か否かを判断する。

通信装置20は、通信装置10のリクエストに対して、リクエスト構文エラーを示す「400 Bad Request」のレスポンスを返す場合、ヘッダテーブル作成機能の整合性を確認するためのダミーレスポンスを送信する(S22)。通信装置20は、ヘッダテーブル作成機能の不整合を検出した場合、通信装置10から受信したリクエストの構文エラーがヘッダテーブル作成機能の不整合に起因すると判断し、通信を終了する。一方、通信装置20は、ヘッダテーブル作成機能の不整合を検出しなかった場合、通信装置10から受信したリクエストの構文エラーがヘッダテーブル作成機能以外に起因すると判断し、通信装置10にリクエストの再送を要求する。

図21のフローチャートによりリクエスト構文エラーを検知した場合にヘッダテーブル作成機能の整合性の確認が必要と判断する手順を示す。なお、図15に示す処理と同様の処理には同一符号(S601-S615)を付して、その詳細説明を省略する。また、整合性の確認する際のダミーレスポンスの送信やリクエストの受信は実施例1と同様であり、その詳細説明を省略する。

HTTP通信制御部307は、通信装置10からのリクエストの受信に成功したか否かを判定し(S606)、リクエストの受信に失敗した場合は、その原因がリクエストの構文エラーによるものか否かを判定する(S807)。構文エラーが原因ではない場合、HTTP通信制御部307は、通信装置10とのHTTP通信接続を切断して(S615)、処理を終了する。

リクエストの受信失敗がリクエストの構文エラーに起因する場合、整合性確認部312は、HTTP通信制御部307を使用して、ヘッダテーブル作成機能の整合性を確認するためのダミーレスポンスを通信装置10に送信する(S808)。ヘッダテーブル作成機能の不整合が検出された場合、メッセージ異常が通信装置10のヘッダテーブル作成部310またはヘッダテーブル更新部311に起因すると判断される。この場合、通信装置20のHTTP通信制御部307は、エラーメッセージを送信して、通信装置10とのHTTP通信接続を切断し、通信装置10との間の通信におけるHTTP/2の使用を中止する。

一方、ヘッダテーブル作成機能の整合性がとれている場合、メッセージ異常が通信装置10のヘッダテーブル作成部310またはヘッダテーブル更新部211に起因しないと判断される。この場合、通信装置20のHTTP通信制御部307は、リクエストの再送を要求する。

このように、通信装置20は、通信装置10とのHTTP通信においてリクエスト構文エラーを検知すると、ヘッダテーブル作成機能と整合性を確認して、HTTPヘッダテーブルを使用するヘッダ圧縮の使用の妥当性を判断する。これにより、HTTPヘッダテーブルの不整合に起因する通信エラーを検出することができ、信頼性が高い通信が可能になる。

［その他の実施例］
本発明は、上述の実施形態の一以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける一以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、一以上の機能を実現する回路（例えば、ASIC）によっても実現可能である。

310 … ヘッダテーブル作成部、311 … ヘッダテーブル更新部、312 … 整合性確認部

Claims

通信相手に送信するメッセージを圧縮し、前記通信相手から受信したメッセージを展開するためのテーブルを作成する作成手段と、
前記送信するメッセージおよび前記受信したメッセージに基づき前記テーブルを更新する更新手段と、
前記テーブルを作成および更新するテーブル作成機能の整合性を判定する判定手段とを有し、
前記判定手段は、前記通信相手に所定のメッセージを送信し、前記通信相手から受信した前記所定のメッセージに基づくリクエストメッセージによって、前記通信相手のテーブル作成機能と自装置のテーブル作成機能の間の整合性を判定する情報処理装置。
前記判定手段は、前記通信相手との通信開始時に前記整合性の判定を行う請求項1に記載された情報処理装置。
前記判定手段は、前記通信相手から受信したメッセージの異常を検知した場合に前記整合性の判定を行う請求項1に記載された情報処理装置。
前記所定のメッセージを受信した前記通信相手は、前記情報処理装置と新たな通信を開始し、前記新たな通信により前記リクエストメッセージの送信を行う請求項1から請求項3の何れか一項に記載された情報処理装置。
前記所定のメッセージを受信した前記通信相手は、
前記テーブルを新規に作成し、
前記所定のメッセージに含まれるHTMLファイルに基づきリクエストメッセージを生成し、
前記新規に作成したテーブルを用いて前記生成したリクエストメッセージを圧縮し、
前記圧縮したリクエストメッセージに基づき前記新規に作成したテーブルを更新し、
前記圧縮したリクエストメッセージを前記情報処理装置に送信する請求項1から請求項4の何れか一項に記載された情報処理装置。
前記リクエストメッセージの生成、前記リクエストメッセージの圧縮、前記テーブルの更新、および、前記リクエストメッセージの送信は、前記HTMLファイルに記載されたリクエストの数分、繰り返される請求項5に記載された情報処理装置。
さらに、前記テーブルを使用して、送信するメッセージを圧縮し、受信したメッセージを展開する圧縮手段を有し、
前記圧縮手段は、前記通信相手から受信したリクエストメッセージを展開し、
前記更新手段は、前記展開されたリクエストメッセージに基づき前記テーブルを更新し、
前記判定手段は、前記更新されたテーブルに記載された情報と、前記HTMLファイルに基づく検証用の情報を比較して前記整合性を判定する請求項5または請求項6に記載された情報処理装置。
前記判定手段は、前記更新されたテーブルに記載されたリクエストヘッダ名およびリクエストヘッダ値のペアと、前記検証用の情報であるリクエストヘッダ名およびリクエストヘッダ値のペアを比較して、それらペアが合致する場合に前記整合性があると判定する請求項7に記載された情報処理装置。
作成手段が、通信相手に送信するメッセージを圧縮し、前記通信相手から受信したメッセージを展開するためのテーブルを作成し、
更新手段が、前記送信するメッセージおよび前記受信したメッセージに基づき前記テーブルを更新し、
判定手段が、前記テーブルを作成および更新するテーブル作成機能の整合性を判定する情報処理方法であって、
前記判定手段は、前記通信相手に所定のメッセージを送信し、前記通信相手から受信した前記所定のメッセージに基づくリクエストメッセージによって、前記通信相手のテーブル作成機能と自装置のテーブル作成機能の間の整合性を判定する情報処理方法。
通信相手に送信するメッセージを圧縮し、前記通信相手から受信したメッセージを展開するためのテーブルを作成する作成手段、および、前記送信するメッセージおよび前記受信したメッセージに基づき前記テーブルを更新する更新手段を有する少なくとも二台の情報処理装置によって構成される情報処理システムであって、
第一の情報処理装置は、前記テーブルを作成および更新するテーブル作成機能の整合性を判定する判定手段を有し、
前記判定手段が、第二の情報処理装置に所定のメッセージを送信し、前記第二の情報処理装置から受信した前記所定のメッセージに基づくリクエストメッセージによって、前記第二の情報処理装置のテーブル作成機能と前記第一の情報処理装置のテーブル作成機能の間の整合性を判定する情報処理システム。
前記所定のメッセージを受信した前記第二の情報処理装置において、
前記作成手段が、前記テーブルを新規に作成し、
生成手段が、前記所定のメッセージに含まれるHTMLファイルに基づきリクエストメッセージを生成し、
圧縮手段が、前記新規に作成されたテーブルを用いて前記生成されたリクエストメッセージを圧縮し、
前記更新手段が、前記圧縮されたリクエストメッセージに基づき前記新規に作成されたテーブルを更新し、
送信手段が、前記圧縮されたリクエストメッセージを前記第一の情報処理装置に送信する請求項10に記載された情報処理システム。
コンピュータを請求項1から請求項8の何れか一項に記載された情報処理装置の各手段として機能させるためのプログラム。
請求項12に記載されたプログラムが記録されたコンピュータが読み取り可能な記録媒体。