The HttpServletRequest breaks down a request into parsed elements, such as request URI, query arguments and headers. Various get methods allow you to access various parts of the request:


The requestURI deals with the URL sent by the browser. For example:


When the server receives this request, the http://server:80 is stripped from the URL, leaving two parts:

In the previous example, the requestURI and queryString are /MyWebApplication/personal/info/top.html and info=intro, respectively.

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 handles 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.

Given the earlier request, the following methods are provided to access the request URI and query string:


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 determine the document root. 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 might leave the pathTranslated and servletPath blank. Servlets in the pipeline are given the responsibility of determining pathTranslated, and splitting servletPath from pathInfo.


HttpServletRequest methods let you access request parameters. The request type determines where the parameters come from. In most implementations, a GET request obtains query string parameters, while a POST request obtains parameters from the posted arguments.

The methods getParameter(), getParameterValues(), and getParameterNames() let you access these arguments. For example, in a GET request with a query string of info=intro the call getParameter("info") returns intro.

Note: If you submit a form with method="POST", the method ServletUtil.getDynamoRequest.getParameter does not return parameter values for query parameters. You must call ServletUtil.getDynamoRequest.getQueryParameter to get query arguments in pages that might get hit from a POSTed form


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 can 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 can do this by adding the session object as an attribute using a well-known attribute name. Subsequent servlets can extract the session object using that name.


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 is 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.

Copyright © 1997, 2013 Oracle and/or its affiliates. All rights reserved. Legal Notices