The HttpServletRequest
breaks a request down into parsed elements, such as request URI, query arguments, headers, etc. Various get
methods allow you to access different parts of the request.
requestURI
The requestURI
deals with the URL sent by the browser. For example, consider the following URL typed into a browser window:
http://server:80/MyWebApplication/personal/info/top.html?info=intro
When the server receives this request, the http://server:80
is stripped from the URL, leaving the requestURI
and the queryString
. In this case, the requestURI
is /MyWebApplication/personal/info/top.html
and the queryString
is anything following the “?” - which in this case would be info=intro
. This will be null if there are no query arguments.
The URI, /MyWebApplication/personal/info/top.html
, is further split up into contextPath
, servletPath
and pathInfo
. This distinguishes the path to a file or other data from the prefix that indicates who is supposed to handle the request. In this case, the /MyWebApplication
might be the contextPath
, /personal
might act as the servletPath
, while the /info/top.html
represents the pathInfo
.
The contextPath
is the name of the J2EE Web application accessed by the requestURI
. One or more contextPaths
can be defined for a Web application in the application.xml
file.
The pathInfo
is usually translated to a real file path by appending it to a document root or Web application root. This real file path is available through getPathTranslated
.
To summarize, given the request http://server:80/personal/info/top.html?info=intro
here are the various ways of accessing the request URI and query string:
Method | Returns … |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The following equations describe the relationships among these properties:
requestURI = contextPath + servletPath + pathInfo
pathTranslated = <documentRoot> + pathInfo
Notice that contextPath
, servletPath,
and pathTranslated
require additional information. For example, to determine the pathTranslated
from the pathInfo
, the Web server must know what the document root is. The Web server uses the application’s application.xml
file to recognize the contextPath
. Or to split the servletPath
from the pathInfo
, the Web server needs to know what prefixes are to be treated specially, such as /personal
. Other requests might not have a contextPath
or servletPath
, and the pathInfo
is not split up at all.
The Web server is not expected to know all of this information. The Web server figures out what it can and leaves the rest blank. For example, the Web server may leave the pathTranslated
and servletPath
blank. Servlets in the pipeline are given the responsibility of determining pathTranslated
, and splitting servletPath
from pathInfo
.
Parameters
The HttpServletRequest
provides methods for accessing parameters of a request. The type of the request determines where the parameters come from. In most implementations, a GET request takes the parameters from the query string, while a POST request takes the parameters from the posted arguments.
The methods getParameter()
, getParameterValues()
, and getParameterNames()
are offered as ways to access these arguments. For example, in a GET request with a query string of “info=intro” the call getParameter("info")
returns "intro"
.
Warning: If you submit a form with method="POST"
, the ServletUtil.getDynamoRequest.getParameter
method does not return parameter values for query parameters. You need to call ServletUtil.getDynamoRequest.getQueryParameter
to get query arguments in pages that might get hit from a POSTed form
Attributes
The request object defines a method called getAttribute()
. The servlet interface provides this as a way to include extra information about the request that is not covered by any of the other HttpServletRequest
methods.
A servlet in the pipeline may use attributes as a way to annotate the request with additional computed information. For example, a servlet in the pipeline might be responsible for reading a cookie from the request, finding a session object corresponding to that cookie, and making that session object available to subsequent servlets in the pipeline. The servlet could do this by adding the session object as an attribute using a well-known attribute name. Subsequent servlets could extract the session object using that name.
ServletInputStream
The ServletInputStream
is an InputStream
that allows your servlets to read all of the request’s input following the headers. For example, the ServletInputStream
can be used to read the incoming submission from a POST argument.
All servlets in the pipeline share the same ServletInputStream
, so if one servlet reads from the stream, the data that is read will no longer be available for other servlets. Certain operations also perform an implicit read on the ServletInputStream
. For example, it was mentioned earlier that in a POST request, the calls to getParameter
return values taken from the posted data. This implies that the posted data has already been read, and is no longer available through the ServletInputStream
. It is instead made available through the parameters.
In general, you should expect to read POST data through parameters rather than the ServletInputStream
. The ServletInputStream
is more useful for reading other forms of request data.