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.
