(57)【特許請求の範囲】
【請求項１】
第一の通信プロトコルを用いた複数のセッションに基づいて、一つ以上のサーバとデータ通信を行う通信手段と、
前記複数のセッションのうち、少なくとも一つのセッションにおけるエラー検出を行う検出手段と、
前記検出手段が、前記複数のセッションのうち第一のセッションにおいてエラーを検出した場合、前記第一の通信プロトコルを用いた前記複数のセッションのうち第二のセッションにおいてデータ通信に用いる通信プロトコルを前記第一の通信プロトコルから第二の通信プロトコルに変更するプロトコル制御手段とを有する情報処理装置。
【請求項２】
前記検出手段により前記第一のセッションにおけるエラーが検出されている場合、前記プロトコル制御手段は、新規に構築するセッションに用いる通信プロトコルを前記第二の通信プロトコルとし、
前記検出手段により前記複数のセッションにおけるエラーが検出されていない場合、前記プロトコル制御手段は、新規に構築するセッションに用いる通信プロトコルを前記第一の通信プロトコルとする請求項１に記載された情報処理装置。
【請求項３】
前記通信手段は、前記複数のセッションに基づいて、前記一つ以上のサーバからコンテンツデータを取得し、
前記検出手段が、第一のドメインに対応するサーバからコンテンツデータを取得するための前記第一のセッションにおけるエラーを検出した場合、前記プロトコル制御手段は、前記複数のセッションのうち、前記第一のドメインに対応するサーバからコンテンツデータを取得するための前記第二のセッションに対応する通信プロトコルを前記第一の通信プロトコルから前記第二の通信プロトコルに変更し、前記複数のセッションのうち、第二のドメインに対応するサーバからコンテンツデータを取得するための第三のセッションに対応する通信プロトコルを変更しない請求項１に記載された情報処理装置。
【請求項４】
前記検出手段が、前記複数のセッションのうち前記第一のセッションにおけるウィンドウサイズに関するエラーを検出した場合、前記複数のセッションのうち前記第二のセッションにおいてデータ通信に用いるウィンドウサイズを変更するウィンドウサイズ制御手段をさらに有する請求項１に記載された情報処理装置。
【請求項５】
複数のタブを有するウェブブラウザに表示させるためのコンテンツデータを、第一の通信プロトコルを用いて一つ以上のサーバから取得する通信手段と、
前記複数のタブのうち、少なくとも一つのタブに対応する通信におけるエラー検出を行う検出手段と、
前記検出手段が、前記複数のタブのうち第一のタブに対応する通信におけるエラーを検出した場合、前記第一の通信プロトコルを用いてコンテンツデータを取得する前記複数のタブのうち第二のタブに対応する通信に用いる通信プロトコルを前記第一の通信プロトコルから第二の通信プロトコルに変更するプロトコル制御手段とを有する情報処理装置。
【請求項６】
前記第一の通信プロトコルはHTTP2.0であり、前記第二の通信プロトコルはHTTP/1.1である請求項１または５に記載された情報処理装置。
【請求項７】
第一の通信プロトコルを用いた複数のセッションに基づいて、一つ以上のサーバとデータ通信を行う通信工程と、
前記複数のセッションのうち、少なくとも一つのセッションにおけるエラー検出を行う検出工程と、
前記検出工程において、前記複数のセッションのうち第一のセッションにおけるエラーが検出された場合、前記第一の通信プロトコルを用いた前記複数のセッションのうち第二のセッションにおいてデータ通信に用いる通信プロトコルを前記第一の通信プロトコルから第二の通信プロトコルに変更するプロトコル制御工程とを有する情報処理方法。
【請求項８】
前記検出工程において前記第一のセッションにおけるエラーが検出された場合、前記プロトコル制御工程において、新規に構築するセッションに用いる通信プロトコルが前記第二の通信プロトコルとされ、
前記検出工程において前記複数のセッションにおけるエラーが検出されない場合、前記プロトコル制御工程において、新規に構築するセッションで用いる通信プロトコルが前記第一の通信プロトコルとされる請求項７に記載された情報処理方法。
【請求項９】
前記通信工程において、前記複数のセッションに基づいて、前記一つ以上のサーバからコンテンツデータが取得され、
前記検出工程において、第一のドメインに対応するサーバからコンテンツデータを取得するための前記第一のセッションにおけるエラーが検出された場合、前記プロトコル制御工程において、前記複数のセッションのうち、前記第一のドメインに対応するサーバからコンテンツデータを取得するための前記第二のセッションに対応する通信プロトコルが前記第一の通信プロトコルから前記第二の通信プロトコルに変更され、前記複数のセッションのうち、第二のドメインに対応するサーバからコンテンツデータを取得するための第三のセッションに対応する通信プロトコルが変更されない請求項７に記載された情報処理方法。
【請求項１０】
複数のタブを有するウェブブラウザに表示させるためのコンテンツデータを、第一の通信プロトコルを用いて一つ以上のサーバから取得する通信工程と、
前記複数のタブのうち、少なくとも一つのタブに対応する通信におけるエラー検出を行う検出工程と、
前記検出工程において、前記複数のタブのうち第一のタブに対応する通信におけるエラーが検出された場合、前記第一の通信プロトコルを用いてコンテンツデータを取得する前記複数のタブのうち第二のタブに対応する通信に用いる通信プロトコルを前記第一の通信プロトコルから第二の通信プロトコルに変更するプロトコル制御工程とを有する情報処理方法。
【請求項１１】
コンピュータを請求項１から６の何れか一項に記載された情報処理装置の各手段として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイトの情報を閲覧するための情報処理に関する。
【背景技術】
【０００２】
一般に、クライアント装置の画面にウェブサイト（以下、Webサイト）のページを表示するには、クライアント装置がWebサイトのデータが保存されたサーバ装置との間でデータ通信を行う必要がある。当該データ通信には、IETF (The Internet Engineering Task Force)によって策定されたHTTP (hypertext transfer protocol)と呼ばれる通信プロトコルが使用される。一般に使われているHTTPのバージョンは1.1であり、HTTP/1.1やHTTP 1.1と表記される。HTTP 1.1は広く普及した通信プロトコルである。
【０００３】
近年、Webサイトに含まれるコンテンツのデータ量が劇的に増加し、多くのWebサイトでアニメーションやインタラクションが含まれるようになった。そのため、高速にデータを通信する仕組みがHTTPに求められている。そこで、IETFは、HTTPの次期バージョンであるHTTP 2.0の策定を開始した（非特許文献1参照）。HTTP 2.0には、クライアント装置とサーバ装置の間でヘッダを送受信する際のヘッダを圧縮する機能（非特許文献2参照）や、データに優先度を与えて通信する機能が盛り込まれている。このため通信速度の改善が期待される。
【０００４】
HTTP 2.0を利用する場合、クライアント装置は、まず、サーバ装置にHTTP 2.0の利用が可能か否かを問い合わせる。問い合わせの結果、HTTP 2.0が利用可能であることが判明すると、HTTP 2.0によって通信を開始する。一方、HTTP 2.0が利用不可であることが判明すると、HTTP 1.1によって通信を開始する。なお、HTTP 2.0による通信は必須ではなく、クライアント装置は、問い合わせを行わずに、HTTP 1.1によって通信を開始してもよい。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】http://www.ietf.org/id/draft-ietf-httpbis-http2-07.txt
【非特許文献２】http://www.ietf.org/id/draft-ietf-httpbis-header-compression-03.txt
【発明の概要】
【発明が解決しようとする課題】
【０００６】
現在、パーソナルコンピュータ(PC)環境、モバイル環境に関わらず、ユーザは、同時に複数のWebサイトの閲覧が可能である。その際、クライアント装置は、複数のセッションを確立し、セッションごとに異なるWebサイトにアクセスしている。
【０００７】
しかし、サーバ装置のHTTP 2.0の実装が正しくない場合、Webサイトの正しい閲覧を行うことができない。一般に、同じドメインでは同じプロトコル実装が利用される。そのため、あるドメインのサーバ装置のHTTP 2.0の実装が正しくないと、そのドメインのWebサイトにアクセスするすべてのセッションが、Webサイトの正しいデータを取得することができない。また、ある時点で正しいデータを取得していたとしても、何れ正しいデータが取得できなくなることが予想される。
【０００８】
また、正しいデータを取得することができなかったWebサイトに再度アクセスする場合、プロトコル実装が正しくないにもかかわらず、サーバ装置からHTTP 2.0が利用可能と通知されたクライアント装置はHTTP 2.0による通信を開始する。そのため、再び、HTTP 2.0を正しく処理することができず、Webサイトの正しい閲覧を行うことができない。
【０００９】
従って、クライアント装置には、複数のセッションの間でHTTP 2.0におけるエラー情報を共有する仕組みや、当該エラー情報を保存する仕組みが望まれる。
【００１０】
本発明は、複数のセッションの間でエラー情報を共有する仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００１２】
本発明にかかる情報処理装置は、第一の通信プロトコルを用いた複数のセッションに基づいて、一つ以上のサーバとデータ通信を行う通信手段と、前記複数のセッションのうち、少なくとも一つのセッションにおけるエラー検出を行う検出手段と、前記検出手段が、前記複数のセッションのうち第一のセッションにおいてエラーを検出した場合、前記第一の通信プロトコルを用いた前記複数のセッションのうち第二のセッションにおいてデータ通信に用いる通信プロトコルを前記第一の通信プロトコルから第二の通信プロトコルに変更するプロトコル制御手段とを有する。
【発明の効果】
【００１３】
本発明によれば、複数のセッションの間でエラー情報を共有する仕組みを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】実施例のクライアント装置である情報処理装置の構成例を説明するブロック図。
【図２】複数のWebページを閲覧する際のブラウザの処理構成を説明するブロック図。
【図３】ブラウザの処理を説明するフローチャート。
【図４】同一ドメインのエラー情報のみを共有する場合の処理を説明するフローチャート。
【図５】実施例2におけるブラウザの処理構成を説明するブロック図。
【図６】実施例2におけるブラウザの処理を説明するフローチャート。
【図７】HTTP 2.0が規定するエラーとエラー情報を受信した場合の処理の関係を説明する図。
【図８】実施例3におけるブラウザの処理を説明するフローチャート。
【発明を実施するための形態】
【００１５】
以下、本発明にかかる実施例の情報処理装置および情報処理方法を図面を参照して詳細に説明する。なお、実施例は特許請求の範囲にかかる本発明を限定するものではなく、また、実施例において説明する構成の組み合わせのすべてが本発明の解決手段に必須とは限らない。
【実施例１】
【００１６】
実施例1として、クライアント装置のウェブブラウザ（以下、ブラウザ）により複数のウェブページ（以下、Webページ）を同時に閲覧する際のエラー処理を説明する。つまり、全セッションでHTTP 2.0のエラー情報を共有し、エラーが発生した場合はセッションを終了し、HTTP 1.1によりセッションの再開を試みる例を説明する。また、本発明は、サーバ装置とクライアント装置の間の通信におけるクライアント装置の仕組みの改良であり、実施例1ではサーバ装置からデータをダウンロードする処理を説明する。
【００１７】
［装置の構成］
図1のブロック図により実施例のクライアント装置である情報処理装置100の構成例を説明する。CPU101は、RAM103をワークメモリとしてROM102や記憶部107に格納されたOSや各種プログラムを実行し、システムバス105を介して情報処理装置100全体を制御する。
【００１８】
ROM102は、変更を必要としないプログラムやパラメータを格納する不揮発性のメモリである。RAM103は、外部から供給されるプログラムやデータ、CPU101の処理の途中で生成されたデータなどを一時的に記憶する揮発性のメモリである。また、記憶部107は、HDDやSSDなどの記憶媒体であり、OS、各種ドライバのソフトウェア、ブラウザなどのアプリケーションプログラム、各種データが格納される。
【００１９】
ディスプレイインタフェイス104は、CPU101の制御に従い、各種情報をモニタ108に表示する。ネットワークインタフェイス106は、CPU101の制御に従い、有線または無線ネットワーク109を介した通信を行う。汎用インタフェイス110は、例えばUSBなどのインタフェイスであり、ユーザ指示を入力するためのマウスやキーボードなどの入力デバイス、メモリカードリーダライタなどを含む各種の入出力デバイス111が接続可能である。
【００２０】
情報処理装置100は、パーソナルコンピュータ(PC)、あるいは、携帯電話、スマートフォン、タブレットデバイスなどの携帯デバイスである。携帯デバイスの場合、タッチパネル機能を有するモニタ108が情報処理装置100に一体に組み込まれる場合がある。
【００２１】
［ブラウザの処理］
図2のブロック図により複数のWebページを閲覧する際のブラウザ200の処理構成を説明する。なお、CPU101は、ユーザ指示に従い、ブラウザ200を起動する。ブラウザ200は、ユーザ指示に従い、図2に示す例においては三つのウェブサイト（Webサイト）にアクセスし、各WebサイトのWebページを各タブウィンドウに表示する。
【００２２】
図2において、ブラウザ200は、Webサイト201-203にアクセスし、各Webサイトとの間でセッション204-206を開始し、タブウィンドウ207-209にWebページを表示する。ブラウザ200は、各タブウィンドウに対応して次の構成を有する。なお、各タブウィンドウに対応する構成は同様であるから、タブウィンドウ207に対応する構成だけを説明する。
【００２３】
データ通信部210は、HTTPプロトコルを使用して、セッション204を介してWebサイト201のサーバ装置との間でヘッダとペイロードから構成されるデータの通信を行う。HTTPレスポンス・リクエスト処理部211は、データ通信部210から入力されるデータをレスポンスデータとして処理し、処理の結果に応じてリクエストデータを生成して、生成したリクエストデータをデータ通信部210に出力するデータ処理部である。エラー情報受信部212は、後述するエラー情報を受信する。
【００２４】
また、ブラウザ200は、タブウィンドウから独立した次の構成を有する。エラー検出部213は、データ通信部210やHTTPレスポンス・リクエスト処理部211で発生したエラーを検出し、検出したエラーを示すエラー情報をRAM103または記憶部107に割り当てられたエラー保存部214に格納する。エラー通知部215は、エラー検出部213がエラーを検出すると、当該エラーを示すエラー情報を各タブウィンドウに対応するエラー情報受信部212に出力する。
【００２５】
エラー検出部213とエラー通知部215は、ブラウザ200の初期の構成ではなく、ブラウザ200に後から組み込み可能な所謂アドオンとして作成し、記録媒体やネットワークを介してブラウザ200に組み込んでもよい。
【００２６】
図3のフローチャートによりブラウザ200の処理を説明する。なお、ブラウザ200が、例えばタブウィンドウ207に対応する処理を開始するとして説明を行う。ブラウザ200は、エラー保存部214にエラー情報が格納されている否かを判定し(S301)、エラー情報が格納されている場合、データ通信部210の通信プロトコルをHTTP 2.0からHTTP 1.1に変更する(S302)。
【００２７】
次に、ブラウザ200は、データ通信部210によってセッション204を開始し、Webサイト201のサーバ装置にリクエストデータを送信する(S303)。その際、ブラウザ200は、クライアント装置上で新しく一つのプロセスを立ち上げ、そのプロセス上でセッションを開始する。同様に、タブウィンドウ208、209に対応するセッションを開始する場合も、新たなプロセスを立ち上げる。
【００２８】
次に、ブラウザ200は、セッション204を終了するか否かを判定する(S304)。セッション204を終了する場合は、データ通信部210によってセッション204を終了し(S315)、タブウィンドウ207に対応する処理を終了する（対応するプロセスを終了する）。一方、セッション204を終了しない場合は、エラー情報受信部212がエラー情報を受信したか否かを判定する(S305)。
【００２９】
エラー情報を受信していないと判定した場合、ブラウザ200は、データ通信部210によってWebサイト201のサーバ装置との間でデータの送受信を行う(S306)。そして、HTTPレスポンス・リクエスト処理部213によって、受信したデータをHTTPのレスポンスデータとして処理を行い、処理の結果に応じてHTTPのリクエストデータを生成する(S307)。
【００３０】
データの送受信およびレスポンスデータの処理中、エラー検出部213は、エラーの発生を監視する(S308)。エラーが発生しなかった場合、ブラウザ200は、処理をステップS304に戻して処理を継続する。一方、エラーが発生した場合、エラー通知部215は、全セッションに対応するエラー情報受信部212にエラー情報を通知し(S309)、エラー検出部213は、エラー情報をエラー保存部214に格納する(S310)。
【００３１】
例えば、タブウィンドウ207-209が開いていて、タブウィンドウ207のHTTPレスポンス処理中にエラーが発生した場合、エラー通知部215は、全タブウィンドウに対応するエラー情報受信部212にエラー情報を通知する。エラー情報の通知方法には、例えば、クライアント装置の実装に依存するプロセス間通信の仕組みを利用する。例えばC言語による実装の場合、pipe()関数やsocket()関数を使ってプロセス間通信を実現することができる。
【００３２】
ステップS305でエラー情報を受信したと判定した場合、または、ステップS310でエラー情報を格納した後、ブラウザ200は、通信プロトコルがHTTP 1.1に変更済みか否かを判定する(S311)。通信プロトコルが変更済みの場合、ブラウザ200は、データ通信部210によってセッション204を終了し(S315)、タブウィンドウ207に対応する処理を終了する。一方、通信プロトコルが未変更の場合、ブラウザ200は、データ通信部210によってセッション204を終了する(S312)。そして、データ通信部210の通信プロトコルをHTTP 2.0からHTTP 1.1に変更し(S313)、データ通信部210によってセッション204を再開して(S314)、処理をステップS304に戻す。
【００３３】
図3に示す処理をクライアント装置上で開いているタブウィンドウすべてにおいて実行することで、複数のセッションの間で非同期的にエラー情報を共有し、エラー情報に応じてデータ通信部210を制御することができる。
【００３４】
●同一ドメインにおけるエラー情報のみの共有
上記では、エラー情報を共有する例を説明したが、同一ドメインにおけるエラー情報のみを共有してもよい。また、エラー保存部214に格納されるエラー情報には、エラーが発生した際の接続先のドメイン情報を付加することができる。図4のフローチャートにより同一ドメインのエラー情報のみを共有する場合の処理を説明する。なお、図4において、図3の処理と同一の処理には同一符号を付し、詳細説明を省略する場合がある。
【００３５】
図3に示す処理との第一の違いは次のとおりである。ブラウザ200は、エラー保存部214にエラー情報が格納されていた場合、これから接続するドメインがエラー情報に付加されたドメイン情報に一致するか否か（同一ドメインか否か）を判定する(S321)。そして、同一ドメインの場合はデータ通信部210の通信プロトコルをHTTP 2.0からHTTP 1.1に変更し(S302)、ドメインが異なる場合は通信プロトコルの変更を行わない。
【００３６】
第二の違いは、全セッションに対応するエラー情報受信部212に通知するエラー情報にドメイン情報を付加する(S323)ことと、エラー保存部214にドメイン情報を付加したエラー情報を格納する(S324)ことである。
【００３７】
第三の違いは次のとおりである。ブラウザ200は、ステップS305でエラー情報受信部212がエラー通知を受信したと判定した後、当該エラー情報に付加されたドメイン情報と接続先のドメインが一致するか否かを判定する(S322)。そして、同一ドメインの場合は処理をステップS311（通信プロトコルが変更済みか否かの判定）に進め、ドメインが異なる場合は処理をステップS306（データ受信）に進める。
【００３８】
図4に示す処理をクライアント装置上で開いているタブウィンドウすべてにおいて実行すれば、複数のセッションの間で非同期的に同一ドメインのエラー情報を共有し、エラー情報に応じてデータ通信部210を制御することができる。
【実施例２】
【００３９】
以下、本発明にかかる実施例2の情報処理装置および情報処理方法を説明する。なお、実施例2において、実施例1と略同様の構成については、同一の符号を付して、その詳細な説明を省略する。
【００４０】
実施例2として、HTTP 2.0において指定可能なウィンドウサイズ（受信バッファサイズ）を全セッションにおいて共有する例を説明する。組込機器などメモリ量が少ない機器においては、適切なウィンドウサイズへの動的な切り替えが求められる。実施例2では、ウィンドウサイズに関するエラーが発生した場合、セッションを終了し、適切なウィンドウサイズへの変更を試み、セッションを再開する例を説明する。また、実施例1と同様に、サーバ装置からデータをダウンロードする処理を説明する。
【００４１】
図5のブロック図により実施例2におけるブラウザ200の処理構成を説明する。図5において図2に示す処理構成と異なるのは、エラー通知部215がウィンドウサイズを含むエラー情報を通知するウィンドウサイズ通知部231に置き換わることである。また、ウィンドウサイズ通知部231によってウィンドウサイズが格納されるウィンドウサイズ保存部230が追加されている。
【００４２】
図6のフローチャートにより実施例2におけるブラウザ200の処理を説明する。なお、ブラウザ200が、例えばタブウィンドウ207に対応する処理を開始するとして説明を行う。ブラウザ200は、ウィドウサイズ保存部230にウィンドウサイズが格納されている否かを判定する(S401)。そして、ウィンドウサイズが格納されている場合は、当該ウィンドウサイズをデータ通信部210に設定する(S402)。
【００４３】
次に、ブラウザ200は、データ通信部210によってセッション204を開始し、Webサイト201のサーバ装置にリクエストデータを送信する(S403)。続いて、セッション204を終了するか否かを判定し(S404)、セッション204を終了する場合は、データ通信部210によってセッション204を終了し(S413)、タブウィンドウ207に対応する処理を終了する。
【００４４】
また、セッション204を終了しない場合、ブラウザ200は、タブウィンドウ207に対応するエラー情報受信部212がエラー情報を受信したか否かを判定する(S405)。エラー情報を受信したと判定した場合、ブラウザ200は、受信したエラー情報に含まれるウィドウサイズをデータ通信部210に設定し(S412)、処理をステップS404に戻して処理を継続する。
【００４５】
また、ウィンドウサイズを受信していないと判定した場合、ブラウザ200は、データ受信部210によってWebサイト201のサーバ装置との間でデータの送受信を行う(S406)。そして、HTTPレスポンス・リクエスト処理部213によって、受信したデータをHTTPのレスポンスデータとして処理を行い、処理の結果に応じてHTTPのリクエストデータを生成する(S407)。
【００４６】
データの送受信およびレスポンスデータの処理中、エラー検出部213は、ウィンドウサイズエラーが発生したか否かを判定する(S408)。ウィンドウサイズエラーは、ブラウザ200が所定のメモリ量よりも多くのメモリを使った場合に発生するエラーである。ウィンドウサイズエラーが発生した場合、メモリ使用量を低減するために、ウィンドウサイズを小さくする必要がある。ただし、小さくするとデータ通信速度が低下するため、ウィンドウサイズを少しずつ小さくする手法が望ましい。
【００４７】
ウィンドウサイズエラーが未発生の場合、ブラウザ200は、処理をステップS404に戻して処理を継続する。一方、ウィンドウサイズエラーが発生した場合、ウィンドウサイズ通知部231は、適切なウィンドウサイズを計算する(S409)。そして、計算したウィンドウサイズを含むエラー情報を全セッションに対応するエラー情報受信部212に通知し(S410)、計算したウィンドウサイズをウィンドウサイズ保存部230に格納し(S411)、処理をステップS412に進める。
【００４８】
図6に示す処理をクライアント装置上で開いているタブウィンドウすべてにおいて実行すれば、適切なウィンドウサイズを共有し、ウィンドウサイズに応じてデータ通信部210を制御することができる。
【実施例３】
【００４９】
以下、本発明にかかる実施例3の情報処理装置および情報処理方法を説明する。なお、実施例3において、実施例1、2と略同様の構成については、同一の符号を付して、その詳細な説明を省略する。
【００５０】
実施例3では、HTTP 2.0に規定されたエラーの種類に応じてブラウザ200の処理を分岐する例を説明する。また、実施例1と同様に、サーバ装置からデータをダウンロードする処理を説明する。なお、ブラウザ200の処理構成は図2と同様である。
【００５１】
図7によりHTTP 2.0が規定するエラーとエラー情報を受信した場合の処理の関係を説明する。図7の左側の三つのカラムは、現在、HTTP 2.0に規定されたエラーの名称、値、内容を示す。クライアント装置やサーバ装置上で動作する通信プログラムは、エラーの値によって、発生したエラーの種類に応じた処理に分岐することができる。実施例3においては、図7に示す12種類のエラーに応じて、次の四種類の処理を選択的に実行する例を説明する。
(1)サーバ装置との通信を継続する（以下、処理1）、
(2)セッションを終了した後にセッションを再開する（以下、処理2）、
(3)セッションを終了した後に通信プロトコルを変更（2.0→1.1）してセッションを再開する（以下、処理3）、
(4)サーバ装置との通信を終了する（以下、処理4）。
ただし、これは一例であって、エラー処理の種類および名称は、ここに示すものに限定されない。
【００５２】
図7の四つ目のカラムは、受信したエラー情報と、エラー情報受信後の処理の対応を示す。NO＿ERRORを受信した場合はエラーなしと判定され、処理1が行われる。また、PROTOCOL＿ERRORを受信した場合は原因を特定することができないため処理3が行われる。なお、ブラウザ200にエラーカウンタをもたせ、PROTOCOL＿ERRORを受信した回数をカウントして、カウント値が所定数以上となった場合は処理4を行ってもよい。
【００５３】
INTERNAL＿ERROR、STREAM＿CLOSED、FRAME＿SIZE＿ERROR、REFUSED＿STREAM、CANCELを受信した場合は、セッション終了後、セッションを再開すればエラーが発生しない可能性がある。そこで、これらのエラー情報を受信した場合は処理2が行われる。
【００５４】
FLOW＿CONTROL＿ERROR、SETTINGS＿TIMEOUT、COMPRESSION＿ERRORを受信した場合、HTTP 2.0のフロー制御処理、SETTINGSフレーム処理、ヘッダ圧縮でエラーが発生したと考えられる。この場合、再びHTTP 2.0によって接続しても同様のエラーが発生する可能性がある。そのため、処理3が行われる。
【００５５】
CONNECT＿ERROR、ENHANCE＿YOUR＿CALMを受信した場合、通信プロトコルに関わらずセッションを再開してもエラーが発生する可能性がある。そのため、処理4が行われる。
【００５６】
図8のフローチャートにより実施例3におけるブラウザ200の処理を説明する。なお、ブラウザ200が、例えばタブウィンドウ207に対応する処理を開始するとして説明を行う。ブラウザ200は、まず、データ通信部210に通信プロトコルにHTTP 2.0を設定し(S601)、データ通信部210によってセッション402を開始し、Webサイト201のサーバ装置にリクエストデータを送信する(S602)。
【００５７】
次に、ブラウザ200は、セッション402を終了するか否かを判定する(S603)。セッションを終了する場合は、データ通信部210によってセッション204を終了し(S611)、タブウィンドウ207に対応する処理を終了する。
【００５８】
また、セッション204を終了しない場合、ブラウザ200は、エラー情報受信部212がエラー情報を受信したか否かを判定する(S604)。エラー情報を受信していないと判定した場合、ブラウザ200は、データ受信部210によってWebサイト201のサーバ装置との間でデータの送受信を行う(S605)。そして、HTTPレスポンス・リクエスト処理部213によって、受信したデータをHTTPのレスポンスデータとして処理を行い、処理の結果に応じてHTTPのリクエストデータを生成する(S606)。
【００５９】
データの送受信およびレスポンスデータの処理中、エラー検出部213は、エラーの発生を監視する(S607)。エラーが発生しなかった場合。ブラウザ200は、処理をステップS603に戻して処理を継続する。一方、エラーが発生した場合、エラー通知部215は、全セッションに対応するエラー情報受信部212にエラー情報を通知し(S608)、処理をステップS609に進める。エラー検出部213は、検出したエラーが図7に示すエラーの何れに相当するかを判定し、判定したエラーに対応する値をエラー情報に含める。また、図8においては省略するが、実施例1と同様に、エラー検出部213はエラー情報をエラー保存部214に格納する。
【００６０】
ステップS604でエラー情報を受信したと判定した場合、または、ステップS608でエラー情報が通知された場合、ブラウザ200は、エラー情報の値（以下、エラー値）が0か否かを判定する(S609)。エラー値が0の場合は処理をステップS603に戻すことで「処理1」を実行する。一方、エラー値が0以外の場合は、エラー値が10または420かを判定し(S610)、エラー値が10または420の場合は、データ通信部210によってセッション204を終了する(S611)。つまり「処理4」を実行してタブウィンドウ207に対応する処理を終了する。
【００６１】
エラー値が10または420ではない場合、ブラウザ200は、、データ通信部210によってセッション204を終了し(S612)、エラー値が1、3、4または9かを判定する(S613)。エラー値が1、3、4、9の何れでもない場合、ブラウザ200は、データ通信部210の通信プロトコルをHTTP 2.0からHTTP 1.1に変更し(S614)、データ通信部210によってセッションを再開する(S615)。つまり「処理3」を実行する。また、エラー値が1、3、4、9の何れかの場合、ブラウザ200は、通信プロトコルを変更せずに、データ通信部210によってセッションを再開する(S615)。つまり「処理2」を実行する。その後、ブラウザ200は、処理をステップS603に戻す。
【００６２】
実施例1においてはセッションにおいて発生したエラーの種類に関わらず、通信プロトコルを変更する例を説明したが、実施例3においては、エラーの種類に応じて通信プロトコルの選択的な変更を行うことができる。その結果、サーバ装置との通信にHTTP 2.0を使う機会を増やすことが可能になる。
【００６３】
［その他の実施例］
本発明は、上述の実施形態の一以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける一以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、一以上の機能を実現する回路（例えば、ASIC）によっても実現可能である。
【符号の説明】
【００６４】
200 … ブラウザ、210 … データ通信部、211 … HTTPレスポンス・リクエスト処理部、213 … エラー検出部、215 … エラー通知部
【図１】
0006389661.tif 000002
【図２】
0006389661.tif 000003
【図３】
0006389661.tif 000004
【図４】
0006389661.tif 000005
【図５】
0006389661.tif 000006
【図６】
0006389661.tif 000007
【図７】
0006389661.tif 000008
【図８】
0006389661.tif 000009