JP2016018281A

JP2016018281A - 情報処理装置および情報処理方法

Info

Publication number: JP2016018281A
Application number: JP2014139160A
Authority: JP
Inventors: 睦池田; Mutsumi Ikeda
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-07-04
Filing date: 2014-07-04
Publication date: 2016-02-01
Anticipated expiration: 2034-07-04
Also published as: WO2016002118A1; JP6389661B2; US10735245B2; US20170085416A1

Abstract

【課題】サーバ装置のHTTP 2.0の実装が正しくない場合でも、ウェブサイトの正しい閲覧ができるようにする情報処理方法を提供する。
【解決手段】ウェブサイトの情報を閲覧するためのブラウザ200は、複数の処理部２０７〜２０９と、処理部において発生したエラーを検出するエラー検出部213、および、検出部213がエラーを検出するとエラーに関する情報を処理部に通知するエラー通知部215を有する。処理部はそれぞれ、ウェブサイトのサーバ装置との間でデータ通信を行うデータ通信部210、および、データ通信部210から入力されるデータをレスポンスデータとして処理し、処理の結果に応じてリクエストデータを生成して、生成したリクエストデータをデータ通信部210に出力するHTTPレスポンス・リクエスト処理部211を有する。処理部は、受信したエラー情報に基づきデータ通信部210を制御する。
【選択図】図２

Description

本発明は、ウェブサイトの情報を閲覧するための情報処理に関する。

一般に、クライアント装置の画面にウェブサイト（以下、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 … エラー通知部

Claims

ウェブサイトの情報を閲覧するための閲覧手段を有し、
前記閲覧手段は、複数の処理手段、前記処理手段において発生したエラーを検出する検出手段、および、前記検出手段がエラーを検出するとエラーに関するエラー情報を前記複数の処理手段に通知する通知手段を有し、
前記複数の処理手段はそれぞれ、前記ウェブサイトのサーバ装置との間でデータ通信を行う通信手段、および、前記通信手段から入力されるデータをレスポンスデータとして処理し、前記処理の結果に応じてリクエストデータを生成して、前記生成したリクエストデータを前記通信手段に出力するデータ処理手段を有し、
前記処理手段は、受信したエラー情報に基づき前記通信手段を制御する情報処理装置。
前記エラー情報を受信した場合、前記処理手段は、前記通信手段がデータ通信に用いる通信プロトコルを変更する請求項1に記載された情報処理装置。
前記情報処理装置は、前記エラー情報が格納される格納手段を有し、
前記格納手段にエラー情報が格納されている場合、前記処理手段は、前記通信手段がデータ通信を開始する前に、前記通信プロトコルの変更を行う請求項2に記載された情報処理装置。
前記エラー情報には、エラーが発生した際の接続先のドメイン情報が含まれ、
前記処理手段は、前記エラー情報に含まれるドメイン情報と前記通信手段の接続先のドメイン情報が一致する場合に前記通信プロトコルの変更を行う請求項2に記載された情報処理装置。
前記情報処理装置は、前記エラー情報が格納される格納手段を有し、
前記格納手段にエラー情報が格納され、かつ、前記エラー情報に含まれるドメイン情報と前記通信手段の接続先のドメイン情報が一致する場合、前記処理手段は、前記通信手段がデータ通信を開始する前に、前記通信プロトコルの変更を行う請求項4に記載された情報処理装置。
前記通信プロトコルはHTTP 2.0からHTTP 1.1に変更される請求項2から請求項5の何れか一項に記載された情報処理装置。
前記エラー情報を受信した場合、前記処理手段は、前記通信手段のウィンドウサイズを前記エラー情報が示すウィンドウサイズに変更する請求項1に記載された情報処理装置。
前記情報処理装置は、前記エラー情報が格納される格納手段を有し、
前記格納手段にエラー情報が格納されている場合、前記処理手段は、前記通信手段がデータ通信を開始する前に、前記通信手段のウィンドウサイズの変更を行う請求項7に記載された情報処理装置
前記エラー情報には、検出されたエラーの種類を示す情報が含まれ、
前記処理手段は、前記エラーの種類に応じて前記通信手段を制御する請求項1に記載された情報処理装置。
ウェブサイトの情報を閲覧するための閲覧手段の情報処理方法であって、
前記閲覧手段が、複数の処理手段、前記処理手段において発生したエラーを検出する検出手段、および、前記検出手段がエラーを検出するとエラーに関するエラー情報を前記複数の処理手段に通知する通知手段を有し、
前記複数の処理手段がそれぞれ、前記ウェブサイトのサーバ装置との間でデータ通信を行う通信手段、および、前記通信手段から入力されるデータをレスポンスデータとして処理し、前記処理の結果に応じてリクエストデータを生成して、前記生成したリクエストデータを前記通信手段に出力するデータ処理手段を有し、
前記処理手段が、受信したエラー情報に基づき前記通信手段を制御する情報処理方法。
コンピュータを請求項1から請求項9の何れか一項に記載された情報処理装置の各手段として機能させるためのプログラム。
請求項11に記載されたプログラムが記録されたコンピュータが読み取り可能な記録媒体。