14. Servlet2.5 制限の緩和・仕様の明確化

仕様上の制限が緩和されたり、明確化された部分があります。

4.1. エラー処理に関する制限緩和

web.xmlの<error-page>要素では、404や500などのエラーが発生したときに遷移させたいエラーページを設定することができます。これまで、その遷移先のサーブレットやJSP内でsetStatusメソッドを呼び出してレスポンスのステータスコードを書き換えることはできないように制限されていたのですが、今回の制限緩和によりそれが無くなりました。

Servletの仕様書を見ると、Servlet2.4のときにあった

If the location of the error handler is a servlet or a JSP page:
The response setStatus method is disabled and ignored if called.

という記述が、Servlet2.5では削除されています。すなわち、エラーページのステータスコードを（例えば404:NOT FOUNDから200:OKに）書き換えられるようになったということです。

これにより、仮にエラーが起こった場合、ただ単にエラーページを表示することしかできなかったこれまでとは違い適切なエラー処理が行えるようになりました。ただしTomcatに関しては、以前からこのような制限は無かったように見受けられます。

4.2. セッション管理に関する制限緩和

RequestDispatcherインタフェースのincludeメソッドによって呼び出されたサーブレットではレスポンスヘッダーを設定できない、という制限があります。これはインクルードされたサーブレットが他に影響を与えないようにするためのものなのですが、クッキーをセットする可能性のあるHttpServletRequest.getSession()メソッドも同様に制限を受けていました。今回の制限緩和で、HttpServletRequest.getSession()メソッドを呼び出す場合に限って許されることになりました。ただし、Tomcatでは少なくともバージョン4以降からこのような動作をしているようです。

4.3. 複数のコンテキストにまたがるセッションの管理法の明確化

複数のコンテキストにまたがるセッションの管理方法に関するルールが、明確化されました。まず、次のような場合を考えてみます。コンテキストAとコンテキストBがあり、コンテキストAの中のサーブレットAは、includeメソッドによってコンテキストBの中のサーブレットBを呼び出しているとします。ここで、クライアントがコンテキストAとセッションAを、コンテキストBとセッションBを同時に持っている場合、サーブレットAからincludeメソッドによって呼び出されたサーブレットBでは、セッションA・Bどちらのセッション情報を参照すればよいのでしょうか。

これまでこの点に関しては明確に仕様で規定されてはいませんでしたが、今回それが明確化され、”あるコンテキストに属するリソースは、クライアントから直接アクセスを受けたか、あるいは他のリソースからディスパッチされたかに関わらず、自身の属するコンテキストのセッション情報を参照する”と規定されました。すなわち先ほどの例で言えば、サーブレットAからincludeメソッドによって呼び出されたサーブレットBでは、セッションAでなくセッションBの情報を参照することになります。