5章 要求 (The Request)

 

要求オブジェクトは、クライアントからの要求の総ての情報をカプセル化する。HTTPプロトコルにおいては、この情報はクライアントからサーバへ要求のヘッダとメッセージ本体により送られる。

 

 

5.1 パラメタ (Parameters)

 

要求パラメタは、クライアントからサーブレット コンテナに要求の一部として送られた文字ストリングである。要求がHttpServletRequestの場合は、属性はURIクエリストリングと、加えて一般的にはクライアントがポストしたフォーム データであろうが、これらを集めたものである。これらのパラメタはサーブレット コンテナに名前−値の対(name-value pair)のセットとして蓄積される。与えられたパラメタ名には複数のパラメタ値が存在し得る。ServletRequestインターフェイスの以下のメソッドは、パラメタへのアクセスの為のものである。

 

-     getParameter

-     getParameterNames

-     getParameterValues

 

getParameterValuesメソッドはパラメタ名に対する総てのパラメタ値を含んだStringオブジェクトの配列を返す。getParameterメソッドで返された値は、何時もgetParameterValuesで返されたStringオブジェクトの配列の最初の値と等しくなければならない。

 

クエリ ストリングとポスト本体からの総てのフォーム データは要求パラメタのセットとして集積される。集積の順番は、クエリ ストリングがポスト本体のパラメタ データに先行する。例えば、クエリ ストリングがa=hello、ポスト本体がa=goodbye&a=worldで要求が構成されていたときは、結果としてのパラメタ セットはa=(hello, goodbye, world)の順番となろう。

 

ポストされたフォーム データは要求の入力ストリームからのみ読み出され、以下の総ての条件に合致したときはパラメタ セットとして集積するのに使用される。

 

1.       該要求がHTTPまたはHTTPS要求である

2.       HTTPメソッドがPOSTである

3.       コンテント タイプがapplication/x-www-form-urlencodedである

4.       サーブレットが該要求オブジェクトのgetParameterファミリのいずれかのメソッドを呼んでいる

 

getParameterファミリのいずれかのメソッドをも読んでいないとき、あるいは上記の全条件が満足されていないときであっても、サーブレットが要求の入力ストリームを通してポスト データを取得できなければならない。

 

つまりサーブレットは、要求データを上記のメソッドを使って取得することも、要求の入力ストリームを読出しながら取得することも可能である。

 

 

5.2 属性 (Attributes)

 

属性は要求に関するオブジェクトである。でなければAPIを介して表現できない情報をコンテナがセットするものであるが、あるいは、サーブレットが他のサーブレットと交信するために(RequestDispatcher経由)セットすることもある。属性はServletRequestインターフェイスの次のメソッドによってアクセス可能である。

 

-     getAttribute

-     getAttributeNames

-     setAttribute

 

ひとつの属性名に対してはただひとつの属性値が附される。

 

”java.”“javax.”のプレフィックスで始まる属性名は本仕様書による定義の為にリザーブされている。同じように”sun.””com.sun.”のプレフィックスで始まる属性名はSun Microsystems社が定義するのに予約されている。属性のセットとして纏められる総ての属性の名前は、Java言語仕様書(http://java.sun.com/docs/books/jls )でパッケージのネーミングで規定された逆パッケージ名規約(reverse package name convention)に準拠することを勧める。

 

 

5.3 ヘッダ (Headers)

 

サーブレットはHTTP要求のヘッダをHttpServletRequestインターフェイスの以下のメソッドを使ってアクセスできる:

 

-     getHeader

-     getHeaders

-     getHeaderNames

 

getHeaderメソッドはヘッダの名前を与えてその値をアクセスする。Cache-Controlヘッダのように多重ヘッダもHTTP要求には存在し得る。ひとつの要求の中に同じ名前のヘッダが複数存在した場合には、getHeaderメソッドは該要求に含まれている最初のヘッダを返す。getHeadersメソッドのほうは、StringオブジェクトのEnumerationで指定したヘッダ名の総てのヘッダ値を返す。

 

ヘッダにはint型あるいはDate型オブジェクトで返したほうが便利なものもある。HttpServletRequestインターフェイスには次のような便利なメソッドが用意されている。

 

-     getIntHeader

-     getDateHeader

 

getIntHeaderメソッドがヘッダ値をint型に変換できないときは、NumbetFormatExceptionがスローされる。getDateHeaderメソッドがDate型に変換できないときにはIlligalArgumentExceptionがスローされる。

 

 

5.4 要求パス要素 (Request Path Elements)

 

サーブレットが要求に対してのサービスに至らしめる要求パスは、多くの重要な区間で構成されている。以下の要素は要求URIパスから取得され、要求オブジェクトを介して知ることが出来る。

 

-     Context Path: このサーブレットが属するServletContextで関連付けられたパスプレフィックス。このコンテキストがWebサーバのURL名空間のベースのルートに配置されているデフォルト(“default”)のコンテキストのときは、このパスは空のストリングである。そうでない時は、このパスは”/”文字で始まるが”/”文字では終端されない。

-     Servlet Path: このパス区間は、この要求を能動化したマッピングに直接対応する。このパスは”/”文字で始まる。

-     PathInfo: Context PathでもServlet Pathでもない要求パスの部分。

 

HttpServletRequestインターフェイスには、以下のメソッドがこの情報のアクセス用に用意されている。

 

-     getContextPath

-     getServletPath

-     getPathInfo

 

URLエンコーディングの要求URIとパス部分間の相違を除いて、以下の式が常に成立することに注意することが重要である:

 

RequestURI = contextPath + sevletPath + pathInfo

 

上記を明確にするための例として、次のものを考えてみよう。/catalogというルート ディレクトリに置かれたlawngardenJSPのサービス サーブレットに対するコンテキストが下表なようなものであるとする:

1Contextセットアップ例

ContextPath

/catalog

Servlet Mapping

Pattern: /lawn

Servlet: LawnServlet

Servlet Mapping

Pattern: /garden

Servlet: GardenServlet

Servlet Mapping

Pattern: *.jsp

Servlet: JSPServlet

 

この場合次のような動作が観察されることになる。

2:パス要素の結果

Request Path

Path Elements

/catalog/lawn/index.html

ContextPath: /catalog

ServletPath: /lawn

PathInfo: /index.html

/catalog/garden/implements/

ContextPath: /catalog

ServletPath: /garden

PathInfo: /implements/

/catalog/help/feedback.jsp

ContextPath: /catalog

ServletPath: /help/feedback.jsp

PathInfo: /null

 

 

5.5 パス変換法 (Path Translation Methods)

 

HttpServletRequestインターフェイスには、プログラム開発者が特定のパスに等価なファイル システム パスを取得するのに便利な以下の二つのメソッドがある。

 

-     getRealPath

-     getPathTransleted

 

getRealPathメソッドは、String型の変数をとり、そのパスに対応するローカル ファイル システム上のファイルをString型で返す。GetPathTranslatedメソッドは、この要求のpathInfoの実際のパスを計算する。

 

サーブレット コンテナがこれらのメソッドに対して有効なファイル パスを求められなかった状態に陥ったとき、例えばアーカイブからWebアプリケーションが実行されたとき、リモートのファイル システムがローカルとしてアクセスできないとき、あるいはデータ ベースのときなどは、これらのメソッドはヌル(null)を返さねばならない。

 

 

5.6 クッキー (Cookies)

 

HttpServletRequestインターフェイスには、その要求に出てきたcookiesの配列を取得する為にgetCookiesメソッドが用意されている。これらのcookiesは、クライアントが作成する各要求にのせ、クライアント側からサーバに送られるデータである。一般的には、クライアントがcookieの部分として送り返す情報はcookie名とcookie値のみである。例えばコメントのように、cookieがブラウザに送られたときにセットされ得るような、その他の属性は、通常は返されない。

 

 

5.7 SSL属性 (SSL Attributes)

 

要求がHTTPSなどの秘匿がかかったプロトコルを介して送られてきたときは、この情報はServletRequestインターフェイスのisSequreメソッドにより開示されねばならない。

 

Java 2 Standard Edition, v.1.2あるいはJava 2 Enterprise Edition, v.1.2環境におけるサーブレット コンテナにおいては、その要求がSSL認証されているときは、java.security.cert.X509Certificate型のオブジェクトの配列としてサーブレットのプログラマに開示されねばならないし、javax.servlet.request.X509CertificateServletRequest属性を介してアクセスできねばならない。

 

Java 2 Standard Edition, v.1.2環境下で動作していないサーブレット コンテナでは、SSL認証情報にアクセスするために固有の要求の属性をベンダが用意してもよい。

 

 

5.8 国際化 (Intenationalization)

 

クライアント側から応答に際してどの言語が好ましいかをサーバに指定することもあろう。この情報は、HTTP/1.1仕様に記述されたほかのメカニズムに併せてAccept-Languageヘッダを附してクライアントから通信できる。ServlerRequestインターフェイスの以下のメソッドが、送信元の指定ロケール(言語地域)を求めるのに用意されている:

 

-           getLocale

-           getLocales

 

getLocaleメソッドは、クライアントがコンテンツを受けるときに好ましいロケールを返す。如何にAccept-Languageヘッダがクライアントの指定言語として解釈すべきかの詳細は、RFC 2626(HTTP/1.1)の第14.4節を参照のこと。

 

getLocalesメソッドは、クライアントが受理可能なロケールであり、指定ロケールから開始するLocaleオブジェクトの降順の列挙型(Enumeration)を返えす。

 

クライアント側から好みのロケールを指定してこないときは、getLocaleメソッドはこのサーブレットコンテナのデフォルトのロケールを返し、getLocalesメソッドはデフォルトロケールのひとつのLocale要素を返さねばならない。