JP2017010388A - Ｈｔｔｐサーバとその制御方法、画像形成装置およびプログラム - Google Patents

Abstract

【課題】IPP（Internet Printing Protocol）Over USBのリクエストを適切に処理することができるHTTPサーバを提供する。【解決手段】HTTPリクエストのホスト名とポート番号とが、HTTPサーバのそれらと一致しない場合には、ホスト名がローカルホストであり、かつ要求元クライアントのアドレスがループバックアドレスであるかを判定しＳ５１１、Ｓ５１２、該当する場合にはHTTPリクエストに対する処理を続行するＳ５０８。【選択図】図５

Description

本発明は、USBインターフェース経由で情報処理装置の設定を行うことが可能なＨＴＴＰサーバとその制御方法、画像形成装置およびプログラムに関する。

インターネットで接続された遠隔地のプリンタに対して印刷を行うための技術としてInternet Printing Protocol (IPP)が存在する。このIPPの拡張としてPCにUSBインターフェースで接続されたプリンタに対してIPPプロトコルで印刷をおこなう、IPP Over USBという技術が存在する。一方、ルータで区切られたネットワークの外部にあるクライアントから、ルータで区切られたネットワークの内部にあるプライベートアドレスが付与されたサーバには直接アクセスできない。そのためネットワークの外部と内部の接続（すなわちネットワーク間の接続の仲介を行う中間サーバにおいて、外部からアクセスされたポート番号により、内部のサーバに対して接続の振り分けを行うポートマッピングという技術が存在する。

特開2005−31725号公報

RFC 2910 Internet Printing Protocol/1.1: Encoding and Transport，インターネット，ＵＲＬ：https://tools.ietf.org/html/rfc2910，２０００年９月

IPP over USBにおいてPC上のWebブラウザからUSBインターフェース経由で画像形成装置(以後MFP)のリモートUIに接続する場合、以下の経路で接続がおこなわれる。
（１）PC上でUSBインターフェースに接続されたMFP毎に仮想サーバが起動される。仮想サーバの動作するポート番号としてはMFP毎に適当な番号が割り当てられる。(例 54321番と54322番)
（２）PC上のWebブラウザは仮想サーバにアクセスを行う。このときHTTPプロトコルのHostヘッダは、PC内部の仮想サーバへのアクセスであるため「Host: localhost:54321」となる。
（３）仮想サーバはWebサーバのからのリクエストを変更せずにUSBのパケットに変換してUSBインターフェースを使用してリクエストをMFPに送信する。
（４）MFP上で動作するUSB-TCP変換モジュールはUSBインターフェースからのパケットを受信すると、USBのパケットに含まれるデータをそのままTCP/IPのパケットに変換する。変換したパケットをMFP上のポート番号8000番で動作している、リモートUIを実現するHTTPサーバに送信する。
（５）HTTPサーバはUSB-TCP変換モジュールから受信したリクエストを処理しようとするが、PC上のWebブラウザから送られたHostヘッダは「Host: localhost:54321」となっている。

このとき、8000番のポートで動作しているHTTPサーバにとって「Host: localhost:54321」であるリクエストはHTTPでは不正なリクエストであるため、HTTPの処理を行うことができなかった。PC上の仮想サーバの動作するポート番号（例えば54321）と同じポート番号で動作するHTTPサーバをMFP上で起動することにより、クライアントから仮想サーバ経由で受信したリクエストが不正なリクエストであることを回避可能である。

しかし、仮想サーバのポート番号には、MFPに接続されるPC毎に、USBポート毎に固有の番号が割り付けられる。そのため予めPC上の仮想サーバの動作するポート番号と同じポート番号で動作するHTTPサーバをMFP側で起動することは困難である。

本発明は上記従来例に鑑みて成されたもので、IPP Over USBのリクエストを受信したHTTPサーバに適切な処理を実行させることを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

クライアントと同じデバイスに置かれたプロキシを経由してHTTPリクエストを送信する前記クライアントと接続されたHTTPサーバであって、
受信したHTTPリクエストが、前記HTTPサーバを指定したもの、または、前記プロキシを経由して送信されたもののいずれかであることを判定する判定手段と、
前記判定手段により前記いずれかである場合には、前記HTTPリクエストに応じて処理をし、いずれでもない場合にはエラーとして処理をする処理手段と
を有することを特徴とするHTTPサーバ。

本発明により、IPP Over USBのリクエストを受信したHTTPサーバは適切な処理を実行することができる。

本発明が実施されるシステムの構成を示す図である。 本発明が実施されるシステムのソフトウェアの構成を示す図である。 本発明のリモートUIを実現するHTTPサーバのソフトウェアの構成を示す図である。 実施形態１でWebブラウザからHTTPサーバに送られるデータを示す図である。 実施形態１の処理のフローチャートである。 実施形態２の処理のシーケンス図である。 実施形態２の処理のフローチャートである。 実施形態２の認証情報チェック処理のフローチャートである。 実施形態２のHTTPプロトコルデータを示す図である。 実施形態２のログインページを示す図である。 実施形態２のリダイレクト先文字列生成処理を示すフローチャートである。 実施形態２のHTTPサーバからWebブラウザに送られるデータを示す図である。 実施形態３のサーブレットからWebブラウザに送られるデータを示す図である。 実施形態３のレスポンスボディ書き込み処理のフローチャートである。 実施形態３のHTTP出力ストリーム取得要求処理のフローチャートである。 実施形態３のボディデータ書き込み処理のフローチャートである。 実施形態３のHTTP出力ストリームクローズ処理のフローチャートである。 USB-TCP変換モジュールのパケット変換処理のフローチャートである。 仮想サーバのパケット変換処理のフローチャートである。

以下、本発明を実施するための形態について図面を用いて説明する。
［実施形態１］
＜システムのハードウェア構成＞
図１は本実施形態のシステム構成図である。本システムはMFP１００とUSBケーブル１０７で接続されたPC１０８で構成される。MFP１００は、本発明を実現するソフトウェアを実行するCPU１０１、本発明を実現するソフトウェアを保存しているROM１０２、本発明を実現するソフトウェアを実行形式で格納するRAM１０４、本発明を実現するソフトウェアがデータを保存する外部記憶装置１０４、USBインターフェースを制御するUSB I/F制御部１０５、ネットワークI/F制御部１０９を含む。上記各モジュールはバス１０６によって相互に接続されておりデータのやり取りをおこなう。MFP１００はネットワークI/F制御部１０９によってネットワーク１１０に接続されている。

＜システムのソフトウェア構成＞
図２は本実施形態のソフトウェアの構成図である。MFP１００上ではHTTPサーバ２０１、USB-TCP変換モジュール２０２が動作している。HTTPサーバ２０１、USB-TCP変換モジュール２０２はローカルネットワーク２０３によって接続されている。ローカルネットワーク２０３は物理的なネットワークであってもよいが、ソフトウェアモジュール間をネットワークに準じたインターフェースで接続するための論理的あるいは仮想的なネットワークであってもよい。例えば、所定のループバックアドレスを指定したIPネットワークなどがローカルネットワーク２０３に該当する。HTTPサーバ２０１はネットワークI/F制御部１０９によりネットワーク１１０と接続されている。USB-TCP変換モジュール２０２はROM１０２からRAM１０４にロードされCPU１０１で実行される。さらにUSB I/F制御部１０５を使用してUSBパケットの送受信をおこなう。

PC１０８においては、MFP１００とUSB１０７で接続されたUSBインターフェース２０５、ポート番号として54321が割り当てられた仮想サーバ２０６、Webブラウザ２０４が動作している。これらの動作については図４等を参照して後述する。またPC１０８は複数のUSBポートを備えており、もうひとつのUSBインターフェース２０７にはMFP209が接続されており、ポート番号として54322が割り当てられた仮想サーバ２０６が稼働している。なおPC１０８のウエブブラウザ２０４はHTTPサーバのクライアントであるので、ウエブブラウザ２０４またはPC１０８をクライアントと呼ぶこともある。さらに仮想サーバ２０６をプロキシと呼ぶ場合もある。

このような構成において、PC１０８から、IPP over USBを用いて、MFP１１０により印刷を行わせることができる。またPC１０８の代わりに、MFP１００がUSBポートに接続されたプリンタサーバがネットワークに接続されているなら、IPP over USBを用いることで、当該プリンタサーバを介して遠隔のクライアントからMFP１００を用いた印刷を実行できる。なおIPPは、背景技術の説明に記載したようにHTTPベースの技術であり、HTTPクライアント（Webブラウザ）とHTTPサーバとの間の通信はHTTPに従って実行される。すなわちTCP/IPをベースとしたHTTPによりIPPのメッセージがクライアントからMFP等のデバイスすなわち画像形成装置１００に送信される。そして、画像形成装置１００では、HTTPのデータを、IPPの規格に従って処理することで、メッセージに従って印刷が実行される。本実施形態はIPP over USBに係るものではあるが、本実施形態の発明は、IPP over USBにより生じるHTTPに関する不整合を解決するものであることから、以下ではHTTPに着目して説明される。

＜ＨＴＴＰサーバ＞
図３はHTTPサーバ２０１のソフトウェアの構成を示す図である。HTTPサーバ２０１は、ネットワーク接続受付部３０１と０個以上のHTTPコネクション３０５、リダイレクト先URL文字列生成部３２２、サーブレット検索部３２３を有する。なおサーブレット３２１はHTTPサーバ２０１に追加されたプログラムモジュールであり、たとえばウエブページを動的に生成するサービスなどを提供する。

ネットワーク接続受付部３０１は、ネットワーク１１０とローカルネットワーク２０３それぞれから８０００番のポートへの接続を待つ。そしてクライアントから８０００番ポートに接続されるとクライアントと通信するための接続ソケット３０６を生成するサーバソケット３０２をもつ。本実施形態ではサーバソケット３０２は８０００番ポートで接続を待っているが他の番号のポートを使用していてもよい。接続ソケット３０６は通信データの読み書きをそれぞれ行うためのソケット入力ストリーム３０７とソケット出力ストリーム３０８をもつ。ソケット３０６は、たとえばコネクションによる通信を実現するためのAPIであり、これを介して通信が行われることから、図３では接続ソケット３０６とネットワーク１１０およびローカルネットワーク２０３とが接続されているように示している。またストリームとは、データの入出力を行うために用意されたクラス或いは機能で、たとえばソケット入力ストリームであればSocketInputStreamなどのクラスとして定義される。しかしながら、本実施形態では、このような特定の言語処理系に依存することなくより一般的な意味でストリームという用語を用いる。すなわち入力ストリームとは例えばファイルのデータを読み込むメソッドおよびデータであり、出力ストリームとは例えばファイルのデータを書き込むメソッドおよびデータである。なお図においては、入力ストリームはInputStream、出力ストリームはOutputStreamなどと英語名称で表記している。

ネットワーク接続受付部３０１はソケット入力ストリーム３０７から読み込んだHTTPのリクエストを受信する。さらにネットワーク接続受付部３０１は、HTTPプロトコルの解釈、認証情報のチェックとHTTPコネクション３０５の生成を行うHTTP受付部３０３をもつ。さらにHTTPサーバ２０１は、HTTP受付部３０３で生成されたHTTPコネクション３０５の通信が終わるまでHTTPコネクション３０５を記憶しているコネクション管理部３０４をもつ。

HTTP受付部３０３はさらに、生成したHTTPコネクション３０５に接続ソケット３０６およびソケット入力ストリーム３０７、ソケット出力ストリーム３０８の情報を設定する。HTTP受付部３０３は接続ソケット３０６のソケット入力ストリーム３０７からHTTPのリクエストヘッダの読み込みをおこなう。さらにHTTP受付部３０３は読み込んだHTTPのリクエストヘッダをHTTPコネクション３０５のHTTPリクエスト３０９のリクエストヘッダのテーブル３１２に設定する。

HTTPコネクション３０５は、一般的には送信元および送信先それぞれのIPアドレスおよびTCPポート番号とプロトコル（図３ではHTTP）との組という、いわゆる５タプルで特定されるコネクションである。図３ではそのようなパラメータで特定されるHTTPサーバ２０１とサーブレット３２１との間の論理的な通信回線であるが、実際上は同一のデバイス上でに実行されるプログラム（またはプロセス或いはスレッド）間の通信を実現している。そのためHTTPコネクションは例えば、そこへの読み書きにより通信を実現するためのメモリ領域そのものである。HTTPコネクション３０５ではHTTPリクエストとHTTPレスポンスがHTTPサーバとサーブレットとの間で交換される。たとえばサーブレットによりHTTPリクエストの受信は、HTTPリクエストオブジェクトにより所定のメソッドを実行することにより行われ、同様にHTTPレスポンスの送信はHTTPレスポンスオブジェクトにより所定のメソッドを実行させることで行われる。以降の説明では、HTTPリクエストやHTTPレスポンスというデータそのものを、オブジェクトと特に区別することなく記載する。したがってたとえばHTTPレスポンスがデータであるかのように送受信の対象として記載されることもあるし、HTTPレスポンスが処理の実行主体として記載されることもある。

ネットワーク接続受付部３０１はHTTPプロトコルの解釈をおこない、HTTPメソッドの取得、リクエストURLの取得、HTTPリクエストヘッダの読み込みを行う。さらにサーブレット検索部３２３を使用しリクエストURLに対応するサーブレットを決定する。ネットワーク接続受付部３０１は決定したサーブレットをHTTPコネクション３０５に設定（接続）する。HTTPコネクション３０５はHTTP受付部３０３に設定された接続ソケット３０６を記憶している。HTTPコネクション３０５はHTTPリクエスト３０９とHTTPレスポンス３１０とを記憶しており、論理的な回線を構成している。

HTTPリクエスト３０９は、HTTP受付部３０３で取得されたHTTPメソッド、リクエストURL、リクエストURLをキーにサーブレット検索部３２３から取得したサーブレット３２１を、あるいはサーブレット３２１を特定する情報を記憶している。HTTPリクエスト３０９は、リクエストヘッダ名３１３とリクエストヘッダ値３１４とを含むリクエストヘッダのテーブル３１２をもつ。HTTPリクエスト３０９は、サーブレット３２１がデータの読み込みを行うためのHTTP入力ストリーム３１５を持つ。

サーブレット３２１はサーブレットの処理に応じてリクエストヘッダのテーブル３１２からリクエストヘッダを取得する。HTTP入力ストリーム３１５はソケット入力ストリーム３０７をラップしたストリームである。したがってHTTP入力ストリーム３１５はソケット入力ストリーム３０７を含み、さらに追加的な機能などを利用できる。サーブレット３２１はHTTP入力ストリーム３１５からリクエストボディを読み込んで処理をおこなう。

HTTPレスポンス３１０はレスポンス３１６、レスポンスヘッダ名３１８とレスポンスヘッダ値３１９から構成されるレスポンスヘッダのテーブル３１７をもつ。さらにサーブレット３２１がデータの書き込みを行うためのHTTP出力ストリーム３２０を持つ。

サーブレット３２１はサーブレットの処理に応じてレスポンスヘッダのテーブル３１７にレスポンスヘッダを追加する。レスポンス３１６と追加されたレスポンスヘッダはサーブレットがレスポンスボディの送信を行う前にソケット出力ストリーム３０８によりクライアントに対して送信される。HTTP出力ストリーム３２０はソケット出力ストリーム３０８をラップしたストリームである。すなわち、HTTP出力ストリーム３２０はソケット出力ストリーム３０８の提供する機能や情報を含む。サーブレット３２１はHTTP出力ストリーム３２０たいしてレスポンスボディを書き込みクライアントに対して送信する。

リダイレクト先URL文字列生成部３２２はサーブレットがリダイレクトレスポンス返す時にレスポンスヘッダであるLocationヘッダに設定するリダイレクト先URLの文字列を生成する。サーブレット検索部３２３はリクエストURLとサーブレットの対応表をもち、HTTP受付部３０３からリクエストURLを引数にサーブレットの要求があると対応するサーブレットを返す。

＜WebブラウザからHTTPサーバに送られるデータの例＞
図４はWebブラウザ２０４からHTTPサーバに送られるデータの一例を示す図である。たとえばWebブラウザ２０４からIPP over USBを用いてMFP１００による印刷を行う場合、ユーザは、Webブラウザ２０４上で所定のアクセス先たとえば仮想サーバ２０６を指定してアクセスを試みる。

これに応じてPC１０８上で動作するWebブラウザ２０４は、同じPC１０８上の54321番ポートで起動している仮想サーバ２０６に対してリクエストをTCPパケット４０１として送信する。

TCPパケット４０１はパケットの送り先が同じPC内の54321番ポートで起動している仮想サーバ２０６であるため宛先であるIPアドレスとTCPポートの組はlocalhost:54321となる。また、TCPパケットに含まれるHTTPプロトコルのデータ４０２のうち、Hostヘッダ値も同じPC内の54321番ポートで起動している仮想サーバ２０６をしめす「localhost:54321」となる。Hostヘッダは、HTTPリクエストのコマンドに含まれており、ホスト名とポート番号とを含む。ホストヘッダは、クライアントがリクエストするサーバ（あるいはサービス）を特定ための識別情報ということもできる。ホスト名localhostは、ループバックデバイスすなわち現在のデバイス自身（この例ではPC１０８）を指し、IPv4では通常127.0.0.1に、IPv6では::1に割り当てられる。すなわちこれらは同じループバックデバイスを指すループバックアドレスあるいはローカルアドレスである。

＜仮想サーバによる処理＞
仮想サーバ２０６は、図１９で示される処理を行い、Webブラウザ２０４から受信したTCPパケット４０１に基づいてUSBパケット４０３の生成、送信をおこなう。

仮想サーバ２０６が起動されると(ステップ１９０１)、仮想サーバ２０６は起動時に指定されたポート番号例えば54321番でサーバソケットをオープンする(ステップ１０９２)。そして仮想サーバ２０６はWebブラウザ２０４からの接続待ちをする（ステップ１９０３）。仮想サーバ２０６の起動は、たとえばWebブラウザの起動と同時であってもよいし、PC１０８の起動をきっかけとしてであってもよい。

仮想サーバ２０６はWebブラウザ２０４から接続されてリクエストを受信すると（ステップ１９０４）、ソケットからWebブラウザ２０４からのリクエストデータを読み込む(ステップ１９０５)。ステップ１９０４で受信するリクエストが図４のTCPパケット４０１に相当する。仮想サーバ２０６はステップ１９０５で読み込んだデータからUSBパケット４０３を生成し（ステップ１９０６）、USBインターフェース２０５を使ってUSBパケット４０３を送信する（ステップ１９０７）。

さらに仮想サーバ２０６はUSBインターフェース２０５からレスポンスデータが返ってくるのを待ち、レスポンスデータのUSBパケットを受信する（ステップ１９０８）。次に仮想サーバ２０６はステップ１９０８で取得したUSBパケットからデータを取得し（ステップ１９０９）、ソケットに取得したデータを書き込み(ステップ１９１０)、ステップ１９０２に遷移して次のWebブラウザ２０４から接続を待つ。

ここで仮想サーバ２０６で生成されるUSBパケット４０３はUSBケーブル１０７で接続されたMFPに割り当てた所定のアドレスおよびポート番号を宛先情報として持つ。さらにUSBパケット４０３はデータ４０４としてTCPパケット４０１のデータ部４０２に含まれるHTTPプロトコルのデータと同じデータをもつ。すなわち、ホストヘッダの内容はTCPパケットからUSBパケットに引き継がれる。

＜USB-TCP変換モジュールによる処理＞
仮想サーバ２０６からUSBインターフェース２０５に対して送信されたUSBパケットはUSBインターフェース２０５やUSB I/F制御部１０５を介してUSB-TCP変換モジュール２０２により受信される。USBパケット４０３を受信したUSB-TCP変換モジュール２０２は図１８の処理をおこないTCPパケット４０５を作成する。さらにUSB-TCP変換モジュール２０２はローカルネットワーク２０３を通じてHTTPサーバ２０１にリクエストを送信する。

USB-TCP変換モジュール２０２が起動する（ステップ１８０１）と、USBからのデータの受信を待つ（ステップ１８０２）。USB-TCP変換モジュール２０２は例えばMFP１００の起動とともに起動される。

USB-TCP変換モジュール２０２は仮想サーバ２０６からデータを受信するとステップ１８０３にすすみ、USBパケット４０３を受信する(ステップ１８０３)。USB-TCP変換モジュール２０２はUSBパケット４０３からデータ４０４を取得する(ステップ１８０４)。USB-TCP変換モジュール２０２は同じMFP上の8000番ポートで起動しているHTTPサーバ２０１に対して接続し（ステップ１８０５）、接続によりえられたソケットに対してデータを書き込む(ステップ１８０６)。ステップ１８０６で書き込まれたデータはTCPパケット４０５としてローカルネットワーク２０３を通じてHTTPサーバ２０１に送信される。TCPパケット４０５の宛先は、USB-TCP変換モジュール２０２が稼働するデバイスと同じMFP１００内の8000番ポートで起動しているHTTPサーバ２０１であるためlocalhost:8000となる。

一方、TCPパケット４０５に含まれるHTTPプロトコルのデータ４０６はUSBパケット４０３のデータ４０４をそのまま送信するため、そこに含まれたHostヘッダ値は「localhost:54321」となる。このように、パケットの宛先は、仮想サーバ２０６とUSB-TCP変換モジュール２０２とにおいて「localhost:54321」→「MFP1」→「localhost:8000」と遷移するのに対して、hostヘッダ値は「localhost:54321」のまま変わることがない。

図５はHTTPサーバ２０１がリクエストを受信した時のHostヘッダのチェック処理を示すフローチャートである。HTTPサーバ２０１がTCPパケット４０５を受け取ると、HTTP受付部３０３はHTTPプロトコルのデータ４０６のリクエスト受信処理を開始する(ステップ５０１)。

HTTP受付部３０３はHTTPプロトコルのデータ４０６を読み込みHTTPリクエスト、リクエストヘッダの取得をおこう。そしてHTTPコネクション３０５を生成して接続ソケット、HTTPリクエスト４０７、リクエストヘッダ４０８の値をHTTPコネクション３０５のHTTPリクエスト３０９に設定する(ステップ５０２)。HTTPリクエスト４０７はサーバに対する要求（メソッド）、リクエスト先をしめすURL、HTTPのバージョン情報から構成され、サーバ上のどのリソースにどのような要求をするかが記述されている。リクエストヘッダ４０８はリクエストに付随する属性情報をサーバに通知するものである。

HTTP受付部３０３はHTTPコネクション３０５のHTTPリクエスト３０９のリクエストヘッダ３１２に保存したHostヘッダの値を取得する（ステップ５０３）。

HTTP受付部３０３はステップ５０３で取得したHostヘッダからホスト名を取得する（ステップ５０４、さらにポート番号を取得する（ステップ５０５）。HTTP受付部３０３はステップ５０４で取得したホスト名がMFP１００のホスト名、MFP１００のIPアドレス、localhost、127.0.0.1のうちのいずれかに該当するかをチェックする（ステップ５０６）。HTTPリクエストヘッダのホスト名が、MFP１００のホスト名、MFP１００のIPアドレスのいずれかであれば、そのパケットはMFP１に宛てられてものである。一方、ホスト名がlocalhost、127.0.0.1のいずれかすなわちループバックアドレスであれば、IPP over USBを用いるべく仮想サーバ２０６を経由してMFP１００に送信されたパケットであると判定できる。ステップ５０６のチェックでHostヘッダのホスト名がMFP１００のホスト名、MFP１００のIPアドレス、localhost、127.0.0.1のいずれかである場合、すなわちMFP１００が受信すべきパケットであれば、ステップ５０７に遷移する、そうでなければステップ５１３に遷移する。

ステップ５０７では、HTTP受付部３０３はステップ５０５で取得したHostヘッダのポート番号がHTTPサーバ２０１が動作しているポート番号（或いはHTTPサーバが接続を監視しているポート番号）と等しいかをチェックする。ステップ５０７のチェックでポート番号が等しければ、すなわちHTTPサーバ２０１に宛てたパケットであればステップ５０８に遷移し、等しくなければステップ５１１に遷移する。受信したHTTPリクエストが仮想サーバ２０６（すなわちプロキシ）に宛てられ、そこで転送されてきた場合にはステップ５０７でノーと判定されてステップ５１１に分岐する。したがってステップ５１１へ分岐した場合、IPP over USBでHTTPリクエストを受信した可能性がある。 ステップ５１１では、HTTP受付部３０３は、ステップ５０４で取得したホスト名がlocalhost、127.0.0.1すなわちループバックアドレスであるかをチェックする。ループバックアドレスは、IPP over USBを用いるべく仮想サーバ２０５を経由して受信したパケットに用いられている。したがってlocalhost、127.0.0.1であればすなわちIPP over USBのパケットの可能性があればステップ５１２に遷移する。localhost、127.0.0.1でなければこのパケットは誤ったパケットとしてステップ５１３に遷移する。

ステッ５１２では、HTTP受付部３０３はHTTPサーバ２０１に接続してきたクライアントのアドレスすなわちリクエストの送信元アドレスがローカルループバックアドレスであるかを調べる（ステップ５１２）。送信元アドレスがローカルループバックアドレスであるのは、送信元がUSB-TCP変換モジュール２０５の場合である。ローカルループバックアドレスであれば、このパケットはIPP over USBのパケットであると判定できるのでステップ５０８に遷移してHTTPの処理を行う。ローカルループバックアドレスでなければ不正なHostヘッダを持つリクエストであると判断して、ステップ５１３に遷移してエラー処理をおこなう。

ステップ５０８でHTTP受付部３０３はHTTPリクエスト４０７のリクエストURLをキーにサーブレット検索部３２３から処理を行うサーブレット３２１を取得しサーブレット３２１に処理を要求する（ステップ５０８）。サーブレット３２１はリクエストを受け取るとレスポンスデータを生成し(ステップ５０９)、生成したレスポンスデータをクライアントに対して送信する（ステップ５１０）。

ステップ５１３でHTTP受付部３０３はエラーレスポンスを生成し、クライアントに対してエラーレスポンスを送信する（ステップ５１４）。

この手順では、図４のTCPパケット４０５に含まれるHTTPプロトコルのデータ４０５のHostヘッダ値は「localhost:54321」であるため、ステップ５０７でステップ５１１に遷移する。TCPパケット４０５はHTTPサーバ２０１と同じMFP１００で動作するUSB-TCP変換モジュール２０２によってローカルネットワークを通じてHTTPサーバに送られる。よってHTTPサーバ２０１に接続してきたクライアントのアドレスはローカルループバックアドレスである。そのためステップ５１２からステップ５０８に遷移し、Hostヘッダ値のポート番号がHTTPサーバ２０１の動作するポート番号と異なっていてもHTTPの処理がおこなわれる。なお、HTTPサーバ２０１が仮想サーバ２０６から受信するパケットの送信元アドレスはループバックアドレスが指定されている。

以上の構成及び手順によって、本実施形態の画像形成装置は、IPP over USBプロトコルに従ってホスト装置であるPC等から受信したHTTPリクエストなどのメッセージを、プロトコルヘッダに含まれた宛先や送信元の情報に基づいてIPP over USBプロトコルのメッセージであるか否か判定する。このため不要なエラーを発生させることなく適切にメッセージを処理することが可能となる。

なお図５のステップ５０６，５０７，５１１，５１２の判定は、この順序で行われなくともよい。正常なHTTPリクエストとして判定される第1のケースは、ホストヘッダのホスト名がMFPまたはローカルホスト（またはループバックアドレス）を示し、かつポート番号がHTTPサーバを示す場合である。このケースは例えばLANを介した或いはデバイス内部からのHTTPサーバに対するリクエストである。ローカルホストとループバックアドレスはローカルデバイス自身を示す点において同じ意味を持つ。第２のケースは、ホストヘッダのホスト名がローカルホスト（またはループバックアドレス）を示し、TCPパケットの送信元アドレスもループバックアドレスを示す場合である。これはクライアントデバイスの内部で当初の送信が行われたことを示しており、仮想サーバを用いるIPP over USBで送信されたリクエストであると判定できる。これら第1のケースと第2のケースとを受け入れ可能なHTTPリクエストと判定する方法であれば、各項目の判定順序はどのようなものであってもよい。

［実施形態２］
実施形態２は実施形態１を前提に実施される。図７は本実施形態においてHTTPのリクエストを受信した時のHTTPサーバ２０１、ユーザ認証をおこなうLogin６０１、リモートUIを提供するRUIサーブレット６３２それぞれの処理を示すフローチャートである。ここでlogin６０１は、認証情報のチェック、ログインページの生成、ログインリクエストの処理を行うモジュールでログイン或いはログインモジュールとも呼ぶ。

HTTPサーバ２０１のHTTP受付部３０３はHTTPのリクエストを受信するとHTTPリクエスト受信処理を開始する（ステップ７０１）。HTTP受付部３０３は実施形態１のHostヘッダのチェックを実施する(ステップ７２２)。ステップ７２２の実体は図５の手順のうちステップ５０２〜Ｓ５０７と５１１〜５１４に相当する。リクエストに対する処理であるステップ５０８および５０９は、図７ではステップ７０２以降で実行される処理に相当する。ここで本フローチャートではステップ７０１においてHostヘッダのチェックが成功したとする。不成功の場合にはステップ５１３、５１４でエラーレスポンスが応答される。

HTTP受付部３０３は、HTTPリクエスト３０９のリクエスト３１１に保存されているリクエストURLがlogin６０１へ認証要求を行うためのURLである「/login」であるかをチェックする(ステップ７０２)。リクエストURLが「/login」であればステップ７１０に遷移する。「/login」でなければステップ７０３に遷移する。

ステップ７０３でHTTP受付部３０３はlogin６０１に対して認証チェック要求をおこなう。これに対してlogin６０１は認証情報チェック処理をおこない、処理結果を示す情報をHTTP受付部３０３に返す（ステップ７０９）。ステップ７０９の詳細は図８で説明する。

ステップ７０５でHTTP受付部３０３はlogin６０１から受信した認証情報チェック処理結果をチェックする（ステップ７０５）。認証がOKであれば、すなわちリクエストに係るユーザがログインユーザであれば、ステップ７０６に遷移する。NGであれば、すなわちリクエストに係るユーザがログインユーザでなければlogin６０１に対して認証レスポンス処理（ステップ７１１、７１２）を要求する。ステップ７１１でlogin６０１はログインをおこなうためのログインページ１００１（図１０参照）を生成し、ステップ７１１で生成したログインページをレスポンスとしてクライアントに返信する(ステップ７１２)。

図１０に示す様に、ログインページ１００１は、IDの入力フィールド１００２、パスワードの入力フィールド１００３、ログイン後に表示する転送先URLの情報１００４、ログインリクエストをサーバに送信するためのLoginボタン１００５を含むよう構成される。転送先URLの情報１００４はHTMLのフォームのhidden要素としてHTMLに記載されている。ユーザがログイン操作を行うと入力されたID、パスワード、ログイン後に表示する転送先URLの情報１００４を含むリクエストボディをもつPOSTリクエストがHTTPサーバ２０１に送信される。ログインページ１００１は、IDとパスワードとを認証情報として使用する認証を行う場合の例である。ログイン後に表示する転送先URLの情報１００４以外は認証方式によって変化してもよい。

認証結果がOKであった場合には、ステップ７０６でHTTP受付部３０３はHTTPリクエストのリクエストURLをキーにサーブレット検索部３２３からサーブレットを取得する（ステップ７０６）。次にステップ７０６で取得したサーブレットに対してページ生成を要求する（ステップ７０７）。図７の例ではリクエストTRLで指定されたサーブレットはリモートUIサーブレット６３２であるものとする。

ページ生成要求をうけたRUIサーブレット６３２はリモートUIのHTMLページを生成する（ステップ７２０）。そしてクライアントに対してステップ７２０で生成したリモートUIのページをレスポンスとしてクライアントに返信し(ステップ７２１)、HTTPリクエスト受信処理を終了する（ステップ７０８）。

一方、login６０１はステップ７１０で、HTTPリクエストのリクエストメソッドがGETであるかPOSTであるかをチェックする（ステップ７１０）。GETであればステップ７１１に遷移してログインページの生成をおこなう。POSTであればステップ７１３に遷移する。ステップ７１３でlogin６０１はPOSTリクエストのリクエストボディを解析してID、パスワード、転送先URLを取得する（ステップ７１３）。転送先URLは、ログインのためのUI１００１に予め設定されて含まれていた転送先URL/RUI１００４である。次にlogin６０１はステップ７１３で取得したIDとパスワードを用いて認証をおこなう（ステップ７１４）。認証がOKであればステップ７１５に遷移する。NGであればステップ７１１に遷移してログインページの生成をおこなう。

ステップ７１５でlogin６０１はログイン済みであることを示すloginsessionデータ（ログインセッションデータ）を生成する（ステップ７１５）。さらにHTTPレスポンス３１０のレスポンスヘッダ３１８にステップ７１５で生成したloginsessionデータをレスポンスヘッダSet-Cookieとして設定する（ステップ７１６）。また生成したloginsessionデータは、現在維持されているセッションを特定するためのデータとしてlogin６０１により保持される。複数のセッションが同時に存在している場合にも、セッションごとにloginsessionデータは生成され、応答され、保持される。レスポンスヘッダはレスポンスデータとしてクライアントに送信されるヘッダ情報である。次にlogin６０１はステップ７１３で取得した転送先URLを引数にHTTPサーバ２０１のリダイレクト先URL文字列生成部３２２に対してリダイレクト先URLの文字列の生成を要求する（ステップ７１７）。login６０１からリダイレクト先URLの文字列の生成を要求されたHTTPサーバ２０１のリダイレクト先URL文字列生成部３２２はリダイレクト先文字列を生成し（ステップ７０４）、login６０１に返す。ステップ７０４の詳細は図１１を参照して説明する。

login６０１はリダイレクト先URL文字列生成部３２２で生成されたリダイレクト先文字列をHTTPレスポンス３１０のレスポンスヘッダ３１８にレスポンスヘッダLocation（レスポンスヘッダロケーション）として設定する（ステップ７１８）。次にlogin６０１はクライアントに対してリダイレクトを要求するリダイレクトレスポンスを返信する(ステップ７１９)。このときのレスポンスヘッダ３１８に保存されている、loginsessionデータが設定されたSet-Cookieヘッダ、Locationヘッダ、そして他のレスポンスヘッダの情報もクライアントに送信される。ここでCookie（クッキー）としてクライアントに返送されたloginsession（ログインセッション）データは、セッションを特定するための情報である。ログインセッションデータはユーザのログインに応じて発行され、当該ユーザがログアウトするまで、クッキーヘッダとして含まれている。

＜認証情報チェック＞
図８はlogin６０１で実行される認証情報チェック(ステップ７０９)のフローチャートである。HTTPサーバ２０１からの要求によりlogin６０１は認証情報チェックを開始する(ステップ８０１)。login６０１はHTTPコネクション３０５のHTTPリクエスト３０９のリクエストヘッダ３１２からCookieヘッダの値を取得する（ステップ８０２）。login６０１はCookieヘッダから認証識別子であるloginsessionの値の取得を試みる（ステップ８０３）。

login６０１はステップ８０３でloginsessionが取得できたかをチェックする（ステップ８０４）。取得できていなければ非ログイン状態としてステップ８０８に遷移し、チェック結果として認証情報チェックNGをHTTPサーバ２０１に返し（ステップ８０８）、認証情報チェック処理を終了する（ステップ８０７。取得できていたらステップ８０５に遷移する。login６０１はステップ８０３で取得したloginsessionが有効な認証識別子であるかをチェックすなわち判定する（ステップ８０５）。

loginsessionが有効であればlogin６０１は認証情報チェックOKをHTTPサーバ２０１に返し（ステップ８０６）、認証情報チェック処理を終了する（ステップ８０７）。無効であれば認証情報チェックNGKをHTTPサーバ２０１に返し（ステップ８０８）、認証情報チェック処理を終了する（ステップ８０７）。有効なloginsessionとは、たとえば、login６０１に現在のセッションを特定する情報として保持されたloginsessionと一致するものである。

＜リダイレクト先URL文字列生成処理＞
図１１はHTTPサーバ２０１のリダイレクト先URL文字列生成部３２２でのリダイレクト先URL文字列生成処理（ステップ７０４）のフローチャートである。リダイレクト先URL文字列生成部３２２はリダイレクト先URL文字列生成処理を開始する（ステップ１１０１）。このときステップ７１３で取得した転送先URLが引数として与えられる。リダイレクト先URL文字列生成部３２２は文字列redirectに「http://」を代入する（ステップ１１０２。リダイレクト先URL文字列生成部３２２はHTTPコネクション３０５のHTTPリクエスト３０９のリクエストヘッダ３１２に保存されているHostヘッダの情報を取得する（ステップ１１０３）。リダイレクト先URL文字列生成部３２２はステップ１１０３で取得したHostヘッダの情報からホスト名を取得する（ステップ１１０４）。さらにポート番号を取得する（ステップ１１０５）。

次にリダイレクト先URL文字列生成部３２２はステップ１１０３で取得したホスト名とステップ１１０４で取得したポート番号とをチェックする（ステップ１１０６）。ステップ１１０６では、取得したホスト名が「localhost」かつ、取得したポート番号が、HTTPサーバ２０１が動作しているポート番号以外の値（たとえば54321）と等しいか判定する。該当すればステップ１１０７に遷移する。該当しなければステップ１１１０に遷移する。ステップ１１０７では、リダイレクト先URL文字列生成部３２２は文字列 redirectにHostヘッダの値を追加する（ステップ１１０７）。たとえばIPP over USBのパケットであれば、ホストヘッダのホスト名はlocalhostであり、かつ、ポート番号は仮想サーバ２０６のポート番号54321であるのでステップ１１０７が実行されて、例えば文字列redirectは「http://localhost:54321」などの値となる。

次にリダイレクト先URL文字列生成部３２２は転送先URLをリクエストパスとして文字列redirectに追加する（ステップ１１０８）。次にリダイレクト先URL文字列生成部３２２はリダイレクト先URL文字列生成処理を終了し（ステップ１１０９）、login６０１に生成したリダイレクト先URLの文字列redirectを返す。

一方、HTTPリクエストのホスト名がlocalhost以外であるか、またはポート番号がHTTPサーバのポート番号8000であるとステップ１１０６で判定された場合には、ステップ１１１０が実行される。ステップ１１１０でリダイレクト先URL文字列生成部３２２は、文字列redirectに、ステップ１１０４で取得したHost名を追加する（ステップ１１１０）。次にリダイレクト先URL文字列生成部３２２は文字列 redirectに「:」を追加する（ステップ１１１１）。次にリダイレクト先URL文字列生成部３２２はHTTPサーバ２０１が動作しているポート番号を文字列redirectに追加し（ステップ１１１２）、ステップ１１０８に遷移する。ステップ１１１２では、たとえば「http://ホスト名:8000」が文字列redirectとして生成される。このようにしてリダイレクト先のURLが生成され、login６０１に返される。

＜実施形態２の処理のシーケンス例＞
図６は実施形態２の処理の一例を示すシーケンス図である。Webブラウザ２０４は仮想サーバ２０５に対してMFP１００の設定を行うためリモートUI（RUI）へのリクエスト９０１を送信する（ステップ６０２）。ここでリクエスト９０１の一例を図９に示した。第１行目はRUIすなわちリモートUIモジュールに対するHTTP/1.1のhttp GETリクエストであることを示し、第２行目にはホストヘッダにホスト名としてlocalhostが、ポート番号として54321が記述され、リクエストの宛先が仮想サーバ２０５であることが示されている。

リクエスト９０１を受信した仮想サーバ２０５は、Webブラウザ２０４から受信したリモートUIへのリクエスト９０１をTCP/IPからUSBパケットに変換してUSBインターフェースを介してUSB-TCP変換モジュール２０２へ送信する（ステップ６０３）。USB-TCP変換モジュール２０２は仮想サーバ２０５から受信したリモートUIへのリクエスト９０１をTCP/IPパケットに再変換してHTTPサーバ２０１に送信する（ステップ６０４）。

HTTPサーバ２０１はLogin６０１に対して認証チェックを要求する（ステップ６０５）。認証チェックを要求されたLogin６０１はステップ７０９（図８参照）の認証チェックを行う。リクエスト９０１にはCookieヘッダがないためloginsessionを取得することができないので、図８のステップ８０８が実行されLogin６０１からは認証チェックNGが返る（ステップ６０６）。そのためステップ７０５のチェックはNGとなりHTTPサーバ２０１はLogin６０１に対してログインページの生成を要求する（ステップ６０７）。

Login６０１は図１０のようなログインページを生成する（ステップ６０８）ので、HTTPサーバ２０１はUSB-TCP変換モジュール２０２に対してレスポンス９０２を返す（ステップ６０９）。レスポンス９０２の例も図９に示す。レスポンス９０２には、リクエストが成功したことを示すコード200 OKと、生成されたログインページとが含まれている。USB-TCP変換モジュール２０２は仮想サーバ２０５に対してレスポンス９０２を返す（ステップ６１０）。仮想サーバ２０５はWebブラウザ２０４にレスポンス９０２を返す（ステップ６１１）。

レスポンスとしてクライアント１０８に送信されたログインページはWebブラウザ２０４により表示される。ログインページ１００１上でユーザによってIDおよびパスワードが入力されてログインボタンが押下されると、Webブラウザ２０４は仮想サーバ２０５に対してログインリクエスト９０３を送信する（ステップ６１２）。ログインリクエスト903の一例も図９に示す。ログインリクエスト903には、Post であること、要求先がlogin６０１であること、httpバージョン1.1であることが示され、ホストヘッダとしてホスト名localhostおよびポート番号54321が示されている。また入力された認証情報であるIDおよびパスワードと、リクエストパスが示されている。図９ではリクエストパスとして「要求ページ/RUI」すなわちRUIに対するリクエストであることおよび要求するページが示されている。

仮想サーバ２０５はWebブラウザ２０４から受信したログインリクエスト９０３をUSB-TCP変換モジュール２０２へ送信する（ステップ６１３）。USB-TCP変換モジュール２０２は仮想サーバ２０５から受信したログインリクエスト９０３をHTTPサーバ２０１に送信する（ステップ６１４）。

ログインリクエスト９０３を受信したHTTPサーバ２０１がログインリクエストのチェック（ステップ７０２）をおこなうと、リクエストURLは「/login」であるためlogin６０１に対して認証処理を依頼する（ステップ６１５）。まずステップ７１０でリクエストメソッドのチェックをおこなうとログインリクエスト９０３のリクエストメソッドはPOSTなのでlogin６０１は図７のステップ７１３〜７１６の認証処理を実行する。さらにlogin６０１はHTTPサーバ２０１に対してダイレクト先URL文字列生成処理（図７のステップ７０４）を要求する（ステップ６１６）。このときパラメータとして、リクエスト９０３に記述されたリクエストパスの一部である「/RUI」を要求と共に送信する。

URL文字列生成処理は、Hostヘッダの値が「localhost:54321」であるため、それにパラメータ「/RUI」を付加して「http://localhost:54321/RUI」というリダイレクト先URL文字列を生成しlogin６０１に返す（ステップ６１７）。HTTPサーバ２０１からリダイレクト先URL文字列が返ってくると、login６０１はLocationヘッダにリダイレクト先URL文字列を設定する(ステップ７１８)。さらに認証レスポンス９０４をHTTPサーバ２０１に返す（ステップ６１８）。認証レスポンス９０４の一例も図９に示す。認証レスポンス９０４は、HTTPステータスコードとして、リクエストされたリソースが一時的に移動していることを示すコード３０２（Moved Temporarily）を持ち、移動先のURLとして生成されたリダイレクト先URL文字列が含まれている。さらに、Set-Cookieとしてセッションを固有に特定するためのloginsessionが設定されている。

HTTPサーバ２０１はUSB-TCP変換モジュール２０２に対して認証レスポンス９０４を返す（ステップ６１９）。USB-TCP変換モジュール２０２は仮想サーバ２０５に対して認証レスポンス９０４を返す６２０。仮想サーバ２０５はWebブラウザ２０４に認証レスポンス９０４を返す（ステップ６２１）。

図１２はHTTPサーバ２０１からWebブラウザ２０４へ６１９〜６２１のシーケンスで送られるパケットを示す図である。ステップ６１９では認証レスポンス９０４のTCPパケット１２０１がHTTPサーバ２０１からUSB-TCP変換モジュール２０２に送られる。このときのTCPパケット１２０１に含まれるデータ１２０２にはHTTPのレスポンスヘッダ「Location： http://localhost:54321/RUI」が含まれている。

USB-TCP変換モジュール２０２でTCPパケット１２０１はUSBパケット１２０３に変換され仮想サーバ２０５に送られる。USBパケット１２０３のデータ１２０４にはHTTPのレスポンスヘッダ「Location： http://localhost:54321/RUI」が含まれている。

USB-TCP変換モジュール２０２でUSBパケット１２０３はTCPパケット１２０５に変換されWebブラウザ２０４に送られる。TCPパケット１２０５に含まれるデータ１２０６にはHTTPのレスポンスヘッダ「Location： http://localhost:54321/RUI」が含まれている。認証レスポンス９０４はステイタス「302」、Locationヘッダ「http://localhost:54321/RUI」、Set−Cookieヘッダ「loginsession=912804821; path=/」を持っている。そのためWebブラウザ２０４は自動的に、同じPC１０８の54321番ポートで動作している仮想サーバ２０５に対してリモートUIへのリクエスト９０５を送信する（ステップ６２２）。さらにWebブラウザ２０４は、図９に示す様に、認証レスポンス９０４のSet−Cookieヘッダで設定されたCookieヘッダ「loginsession=912804821」をリモートUIへのリクエスト９０５に含める。

仮想サーバ２０５はWebブラウザ２０４から受信したリモートUIへのリクエスト９０５をUSB-TCP変換モジュール２０２へ送信する（ステップ６２３）。USB-TCP変換モジュール２０２は仮想サーバ２０５から受信したリモートUIへのリクエスト９０５をHTTPサーバ２０１に送信する（ステップ６２４）。

HTTPサーバ２０１はLogin６０１に対して認証チェックを要求する（ステップ６２５）。認証チェックを要求されたLogin６０１はステップ７０９の認証チェックを行う。リクエスト９０５はCookieヘッダ「loginsession=912804821」をもつのでステップ８０４のチェックではステップ８０５に遷移する。このログインセッションは有効であるのでステップ８０６に進みLogin６０１は認証チェックOKをHTTPサーバ２０１に返す（ステップ６２６）。

Login６０１から認証チェックOKがかえってきたのでHTTPサーバ２０１はステップ７０６に進みサーブレット検索部３２３からリクエストURL 「/RUI」をキーにサーブレットを取得する（図７のステップ７０６）。次にステップ７０６で取得したRUI サーブレット６３２に対してRUIページ生成を要求する（図７のステップ７０７、６２７）。

RUIサーブレット６３２はRUIページを生成し（図７のステップ７２０）、RUIレスポンス９０６を返す（ステップ６２８）。RUIレスポンスにはリクエストされたRUIページが含まれている。HTTPサーバ２０１はUSB-TCP変換モジュール２０２に対してRUIレスポンス９０６を返す（ステップ６２９）。USB-TCP変換モジュール２０２は仮想サーバ２０５に対してRUIレスポンス９０６を返す６３０。仮想サーバ２０５はWebブラウザ２０４にRUIレスポンス９０６を返す（ステップ６３１）。

このようなシーケンスにより、Webブラウザ２０４はRUIレスポンス９０６を受信し、リモートUIの画面の表示を行う。以後、リモートUIによるMFP１００の設定操作は６２２〜６３１のシーケンスと同様に実行される。

以上のようにして、ログインリクエストに対して画像形成装置１００から仮想サーバ２０５へと指定したURLへとリダイレクトさせる応答をWebブラウザ２０４に返すことで、Webブラウザ２０４によりログイン後に仮想サーバへとリクエストを送信させることができる。

［実施形態３］
実施形態３は実施形態１、２を前提に実施される。図１４はサーブレット３２１によるレスポンスボディデータ書き込み処理のフローチャートである。サーブレット３２１はレスポンスボディデータ書き込み処理を開始する(ステップ１４０１)。なお本実施形態ではHTTPレスポンスは単なる応答データではなくオブジェクトとしてその説明が記載される。したがって、例えば図１４、図１５などでは、HTTPレスポンスが実行主体として処理を遂行するような記載がある。これはHTTPレスポンスオブジェクトに定義されたメソッドの実現であり、たとえば実行主体はサーブレット３２１であり、サーブレット３２１が呼び出した手続きによりHTTPレスポンスが作成されるものと理解してもよい。

図１４において、まず、サーブレット３２１はHTTPレスポンス３１０からHTTP出力ストリーム３２０を取得する（ステップ１４０２）。サーブレット３２１はステップ１４０２で取得したHTTP出力ストリーム３２０に対してサーブレット３２１固有のロジックにより生成されたボディデータの書き込みを行う（ステップ１４０３）。さらにサーブレット３２１はサーブレット３２１が書き込むべきボディデータのすべての書き込みが完了したかを判断する（ステップ１４０４。終了してなければステップ１４０３に遷移し書き込みを続行する。終了していればステップ１４０５に遷移する。ボディデータの書き込みが完了したらサーブレット３２１はHTTP出力ストリーム３２０のクローズ処理を行い（ステップ１４０５）、スポンスボディデータ書き込み処理を完了する(ステップ１４０６)。

図１５はステップ１４０２でのHTTP出力ストリーム３２０取得の詳細な処理のフローチャートである。ここで実行主体として記載するHTTPレスポンスは単なる応答データではなく、前述したようにオブジェクトであってメソッドを実行できる。そのためHTTPレスポンスは、ここではひとつのプログラムモジュールとみなされてもよい。

サーブレット３２１からHTTP出力ストリーム３２０取得要求が行われるとHTTPレスポンス３１０はHTTP出力ストリーム３２０取得処理を開始する（ステップ１５０１）。HTTPレスポンス３１０はレスポンスヘッダ３１７にContent-Lengthヘッダが設定されているかをチェックする（ステップ１５０２）。設定されていなければChunked Encoding（チャンク形式エンコーディング）によるボディデータの送信をおこなうとしてステップ１５０３に遷移する。設定されていたらContent-Length（コンテンツ長）ヘッダの情報をつかって送信データサイズの管理を行うとしてステップ１５０６に遷移する。なお、チャンク形式エンコーディングは、ボディデータすなわち送信対象のデータを任意のサイズの塊（チャンク）に分割し、チャンクのサイズを記述したヘッダを付加するエンコード方式である。

HTTPレスポンス３１０はHTTPリクエスト３０９のリクエストヘッダ３１２に保存されているHostヘッダの情報を取得するに。さらにHost名がlocalhostかつ、ポート番号が、HTTPサーバ２０１が動作しているポート番号（例えば8000）以外の番号であるかをチェックする（ステップ１５０３）。ステップ１５０３の判定結果がイエス、すなわちホスト名がlocalhostかつHTTPサーバ２０１が動作しているポート番号以外の番号である場合はステップ１５０４に遷移する。そうでなければあればステップ１５０９に遷移する。

ステップ１５０４でHTTPレスポンス３１０はChunked Encodingによるボディデータの送信かつポート番号置換をおこなうHTTP出力ストリーム１５１０を生成する。そして生成したHTTP出力ストリーム１５１０をサーブレット３２１に対して返す。そしてHTTP出力ストリーム３２０取得処理を終了する（ステップ１５０５）。

ステップ１５０９でHTTPレスポンス３１０はChunked Encodingによるボディデータの送信をおこなうHTTP出力ストリーム１５１１を生成しサーブレット３２１に対して返す。そしてHTTP出力ストリーム３２０取得処理を終了する（ステップ１５０５）
ステップ１５０６でHTTPレスポンス３１０はHTTPリクエスト３０９のリクエストヘッダ３１２に保存されているHostヘッダの情報を取得する。そしてHost名がlocalhostかつ、ポート番号がHTTPサーバ２０１が動作しているポート番号以外の番号であるかをチェックする（ステップ１５０６）。ステップ１５０６の判定結果がイエス、すなわちホスト名がlocalhostかつHTTPサーバ２０１が動作しているポート番号以外の番号である場合、ステップ１５０７に遷移する、そうでなければステップ１５０８に遷移する。

ステップ１５０７でHTTPレスポンス３１０はContent-Lengthヘッダによるボディデータの送信かつポート番号置換をおこなうHTTP出力ストリーム１５１２を生成する。そして生成したHTTP出力ストリーム１５１２をサーブレット３２１に対して返す（ステップ１５０７）。そしてHTTP出力ストリーム３２０取得処理を終了する（ステップ１５０５）。

ステップ１５０８でHTTPレスポンス３１０はContent-Lengthヘッダによるボディデータの送信をおこなうHTTP出力ストリーム１５１３を生成しサーブレット３２１に対して返す（ステップ１５０８）。そしてHTTP出力ストリーム３２０取得処理を終了する（ステップ１５０５）。

図１６はステップ１４０３でのHTTP出力ストリーム３２０へのボディデータの書き込み処理の詳細なフローチャートである。サーブレット３２１からHTTP出力ストリーム３２０にボディデータの書き込みがおこなわれるとボディデータ書き込み処理が開始される（ステップ１６０１）。ここでの処理のソフトウェア上の主体はHTTP出力ストリーム３２０であり、出力ストリームと同様にたとえばHTTP出力ストリームオブジェクトに定義されたメソッドの実行により実現される。

HTTP出力ストリーム３２０がChunked Encodingによるボディデータの送信かつポート番号置換をおこなうHTTP出力ストリーム１５１０の場合はステップ１６０２から処理を行う。

ステップ１６０２ではHTTP出力ストリーム３２０はサーブレット３２１から書き込まれたデータに含まれるリンク情報をチェックする。ホスト名がlocalhostで、かつポート番号がHTTPサーバ２０１が動作しているポート番号のリンク情報を含む場合、ステップ１６０３に遷移する。含まない場合ステップ１６０４に遷移する。ステップ１６０３でHTTP出力ストリーム３２０はポート番号をリクエストヘッダ３１２に保存されているHostヘッダに記載されたポート番号（すなわちサーバのポート番号以外の番号）に置換する（ステップ１６０３）。ステップ１６０４でHTTP出力ストリーム３２０はデータの長さを計りチャンクサイズを決定する（ステップ１６０４）。なお、RUIのサーブレット３２１が書き込むクライアントへの応答データの実体には、クライアントに提示するページを示すホスト名とポート番号のリンク（参照）を含んでいる。

ステップ１６０５でHTTP出力ストリーム３２０はステップ１６０４で計算したチャンクサイズとデータを出力ストリーム３０８に書き込み、ボディデータ書き込み処理を終了する（ステップ１６０６）。

HTTP出力ストリーム３２０がChunked Encodingによるボディデータの送信をおこなうHTTP出力ストリーム１５１１の場合はステップ１６０４から処理を行う。HTTP出力ストリーム３２０がContent-Lengthヘッダによるボディデータの送信かつポート番号置換をおこなうHTTP出力ストリーム１５１２の場合はステップ１６０７から処理を行う。

ステップ１６０７でHTTP出力ストリーム３２０はサーブレット３２１から書き込まれたデータにlocalhostかつHTTPサーバ２０１が動作しているポート番号のリンクを含むかをチェックする(ステップ１６０７)。含む場合、ステップ１６０８に遷移する。含まない場合ステップ１６０９に遷移する。ステップ１６０８でHTTP出力ストリーム３２０はポート番号をリクエストヘッダ３１２に保存されているHostヘッダに記載されたポート番号に置換する（ステップ１６０８）。ステップ１６０９でHTTP出力ストリーム３２０はデータを一時保存領域に保存し（ステップ１６０９）、ボディデータ書き込み処理を終了する（ステップ１６０６）。

HTTP出力ストリーム３２０がContent-Lengthヘッダによるボディデータの送信をおこなうHTTP出力ストリーム１５１３の場合はステップ１６１０から処理を行う。ステップ１６１０でHTTP出力ストリーム３２０はサーブレット３２１からの最初の書き込みであるかを判断する（ステップ１６１０）。最初の書き込みであればステップ１６１２に遷移する。最初の書き込みでなければステップ１６１１に遷移する。ステップ１６１２でHTTP出力ストリーム３２０は出力ストリーム３０８にレスポンスヘッダのテーブル３１７に保存されているContent-Lengthヘッダの情報を書き込む(ステップ１６１２)。そしてステップ１６１１に遷移する。Content-Lengthヘッダの情報はサーブレット３２１がレスポンスボディデータの書き込み処理を開始する前にサーブレット３２１によって計算されレスポンスヘッダのテーブル３１７保存されている。ステップ１６１１でHTTP出力ストリーム３２０はデータを出力ストリーム３０８に書き込み、ボディデータ書き込み処理を終了する（ステップ１６０６）。

図１７はステップ１４０５のHTTP出力ストリーム３２０のクローズ処理の詳細なフローチャートである。サーブレット３２１からHTTP出力ストリーム３２０のクローズがおこなわれるとクローズ処理が開始される（ステップ１７０１）。

HTTP出力ストリーム３２０が１５１０、１５１１または１５１３のHTTP出力ストリームの場合ステップ１７０２から処理を行う。ステップ１７０２でHTTP出力ストリーム３２０はクローズ処理を行い（ステップ１７０２）、HTTP出力ストリーム３２０のクローズ処理を終了する（ステップ１７０３）。

一方HTTP出力ストリーム３２０がContent-Lengthヘッダによるボディデータの送信かつポート番号置換をおこなうHTTP出力ストリーム１５１２の場合ステップ１７０４から処理を行う。ステップ１７０４でHTTP出力ストリーム３２０はステップ１６０９でデータを一時保存した一時保存領域に保存されているデータのサイズ（データ長）を計測する（ステップ１７０４）。次に、ステップ１７０４で取得したデータのサイズをContent-Lengthヘッダの値として出力ストリーム３０８に書き込む（ステップ１７０５）。さらにHTTP出力ストリーム３２０はステップ１６０９でデータを一時保存した一時保存領域に保存されているデータを出力ストリーム３０８に書き込み（ステップ１７０５）、ステップ１７０２に遷移する。

以上の手順により、サーブレット３２１からのHTTPレスポンスデータを出力ストリームを介してHTTPサーバに引き渡すことができる。この際に、処理対象がIPP over USBのパケットであるか否かをHTTPリクエストのhostヘッダに含まれたホスト名およびポート番号に基づいて判定し、IPP over USBであると判定すれば、HTTPレスポンスデータに含まれたリンクを、仮想サーバのポート番号へと書き換える。

図１３はサーブレット３２１が生成したボディデータがWebブラウザ２０４送信される時のデータの変化を示す図である。サーブレット３２１はレスポンスのボディデータとしてホスト名とポート番号例えばlocalhost:8000を含むデータ１３０１を書き込む。リクエストのHostヘッダがlocalhostかつポート番号がHTTPサーバ２０１が動作しているポート番号以外の番号である場合、HTTP出力ストリーム１５１０または１５１２が使用される。そのためポート番号書き換え処理（ステップ１６０３、１６０８）が実行され、HTTPサーバ２０１がUSB−TCP変換モジュール２０２に送るパケット１３０２に含まれるデータは、ポート番号が、HTTPリクエストのhostヘッダに書き込まれていたポート番号に置換されたデータ１３０３となる。

USB−TCP変換モジュール２０２はTCPパケット１３０２に含まれるデータ１３０３を取り出し、USBパケット１３０４を生成し仮想サーバ２０６に送信する。TCPパケット１３０２に含まれるデータ１３０３とUSBパケット１３０４に含まれるデータ１３０５は同じポート番号を含むデータである。

USBパケット１３０４を受信した仮想サーバ２０６はUSBパケット１３０４からデータ１３０５を取り出し、TCPパケット１３０６を生成しWebブラウザ２０４に送信する。USBパケット１３０４に含まれるデータ１３０５とTCPパケット１３０６に含まれるデータ１３０７とは同じポート番号を含むデータである。

TCPパケット１３０６を受信したWebブラウザ２０４はTCPパケット１３０６に含まれるデータ１３０７をリンクとして表示する。ユーザがこのリンクをクリックするとPC１０８の54321番ポートで動作している仮想サーバ２０６にリクエストが送信され、USBインターフェース経由で、MFP１００で動作しているHTTPサーバ２０１０を利用することが可能となる。

以上のようにして、IPP over USBプロトコルを用いてホスト装置と、HTTPサーバがインストールされたUSBデバイスである画像形成装置とを接続したネットワークシステムにおいて、仮想サーバを経由することに起因して生じ得る障害を解消することができる。具体的には、ホスト装置からUSBデバイスへのデータ送信は、HTTPからUSBへのプロトコル変換を実行する、ホスト装置内の仮想サーバを経由する。そのため、HTTPリクエストのhostヘッダに含まれたホストのポート番号と、TCPの送信元ポート番号との不一致が生じ、それがHTTPサーバにおけるエラーをもたらす。そこで、HTTPリクエストの元々の送信先が仮想サーバであれば、リクエストを成功として処理することでエラーを回避する（実施形態１）。

さらに、USBデバイスによってクライアントにリダイレクトを行わせる際に、リダイレクト先がHTTPサーバであれば、HTTPサーバに代えて仮想サーバのポートを指定しておくことで、IPP over USBプロトコルを用いた仮想サーバ経由のリダイレクトが可能となる（実施形態２）。

さらに、クライアントに応答するHTTPレスポンスの実体にHTTPサーバへのリンクが含まれている場合には、HTTPサーバに代えて仮想サーバのポートを指定しておくことで、IPP over USBプロトコルを用いた仮想サーバ経由の参照が可能となる（実施形態３）。

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

Ｓ５０３ Hostヘッダのホスト名判定処理、Ｓ５０４ Hostヘッダのポート番号判定処理、Ｓ５０８クライアントのアドレスがローカルループバックアドレスであるかの判定処理

Claims (12)

1. クライアントと同じデバイスに置かれたプロキシを経由してHTTPリクエストを送信する前記クライアントと接続されたHTTPサーバであって、
   受信したHTTPリクエストが、前記HTTPサーバを指定したもの、または、前記プロキシを経由して送信されたもののいずれかであることを判定する判定手段と、
   前記判定手段により前記いずれかである場合には、前記HTTPリクエストに応じて処理をし、いずれでもない場合にはエラーとして処理をする処理手段と
   を有することを特徴とするHTTPサーバ。
2. 前記判定手段は、前記HTTPリクエストのホストヘッダに含まれたポート番号が前記HTTPサーバのポート番号ではなく、前記ホストヘッダに含まれたホスト名がローカルホストを示し、かつ前記HTTPリクエストの送信元のアドレスがループバックアドレスである場合に、前記HTTPリクエストが、前記プロキシを経由して送信されたものであると判定することを特徴とする請求項１に記載のHTTPサーバ。
3. 前記判定手段は、前記HTTPリクエストのホストヘッダに含まれたホスト名が、前記HTTPサーバがインストールされたデバイスを示し、前記ホストヘッダに含まれたポート番号が前記HTTPサーバのポート番号である場合に、前記HTTPリクエストが、前記HTTPサーバを指定したものであると判定することを特徴とする請求項１または２に記載のHTTPサーバ。
4. 前記HTTPリクエストのホストヘッダに含まれたホスト名がローカルホストであり、かつ前記ホストヘッダに含まれたポート番号が前記HTTPサーバのポート番号以外の番号である場合には、前記ホストヘッダに含まれた前記ポート番号をリダイレクト先のポート番号としてリダイレクト先文字列を生成する手段を更に有し、
   前記処理手段は、リダイレクト先として前記リダイレクト先文字列を含むHTTPレスポンスを応答することを特徴とする請求項１乃至３のいずれか一項に記載のHTTPサーバ。
5. 前記HTTPリクエストのホストヘッダに含まれたホスト名がローカルホストであり、かつ前記ホストヘッダに含まれたポート番号が前記HTTPサーバのポート番号以外の番号である場合、前記処理手段は、前記HTTPリクエストの送信元への応答データに含まれたリンク情報に含まれたポート番号を、前記ホストヘッダに含まれた前記ポート番号に変換することを特徴とする請求項１乃至４のいずれか一項に記載のHTTPサーバ。
6. 前記処理手段はさらに、前記ポート番号の変換によって変わった前記データの長さを前記応答データのデータ長さ情報として送信することを特徴とする請求項５に記載のHTTPサーバ。
7. 請求項１乃至６のいずれか一項に記載のHTTPサーバを含むことを特徴とする画像形成装置。
8. 前記クライアントと前記画像形成装置とはUSBインターフェースを介して接続され、
   前記クライアントは前記画像形成装置のHTTPサーバに対する前記HTTPリクエストをTCPパケットで前記プロキシに対して送信し、
   前記プロキシは、受信した前記TCPパケットをUSBパケットに変換するとともに、パケットの宛先を前記画像形成装置の前記HTTPサーバに書き換えて転送し、
   前記画像形成装置は、前記USBパケットを受信して前記TCPパケットに変換するとともに、パケットの宛先をローカルホストのHTTPサーバに書き換えて転送することを特徴とする請求項７に記載の画像形成装置。
9. 前記クライアントと前記画像形成装置とはIPP over USBプロトコルで接続されることを特徴とする請求項７または８に記載の画像形成装置。
10. 請求項１乃至６のいずれか一項に記載のHTTPサーバとしてコンピュータを機能させるためのプログラム。
11. 請求項７乃至９のいずれか一項に記載の画像形成装置としてコンピュータを機能させるためのプログラム。
12. クライアントと同じデバイスに置かれたプロキシを経由してHTTPリクエストを送信する前記クライアントと接続されたHTTPサーバの制御方法であって、
    受信したHTTPリクエストが、前記HTTPサーバを指定したもの、または、前記プロキシを経由して送信されたもののいずれかであることを判定する判定工程と、
    前記判定工程により前記いずれかである場合には、前記HTTPリクエストに応じて処理をし、いずれでもない場合にはエラーとして処理をする処理工程と
    を有することを特徴とするHTTPサーバの制御方法。

Images