Clarify the limitations on using the request and response from an application thread

Section 2.3.3.4 of the Servlet 3.0 spec gives this advice on thread safety with regards to using the request and response objects in an async scenario:

"... they should either only be used within the scope of the request handling thread or the application must ensure that access to the request and response objects are thread safe."

This makes it clear they're not thread safe but also gives the impression that as long as access to these objects is synchronized, they can be used. However, in this [servlet-spec user discussion](http://java.net/projects/servlet-spec/lists/users/archive/2012-05/message/10), Greg Wilkins suggests there are a number of request methods that should probably never be used from an async thread including the **context path**, **servlet path**, **path info**, **request URI**, getting a **RequestDispatcher**, accessing the **session** (and possibly others) since their values may change.

Not surprisingly the behavior of Servlet containers varies. The scenario mentioned by Greg actually works in Tomcat and Glassfish potentially leading one to believe it's portable code. Even if one didn't intend on switching containers or didn't care about writing portable code, it's still not clear if the request and response can be used reliably or if they just happen to work in some scenarios.

The spec should make it clear what parts of the request and response should not be used from an application thread in an async scenario.