I keep forgetting these value. So I'm writing it down here to remember
Within a servlet, or Filter (or jsp) you can access the following information about the request.
httpRequest.getContextPath(); // =/webapp
httpRequest.getRequestURI(); // =/webapp/webhome
httpRequest.getServletPath(); // = /webhome
httpRequest.getRequestURL(); // = http://mybox.my:11600/webapp/webhome?q=query&r=prevPage
httpRequest.getRequestURI(); // = http://mybox.my:11600/webapp/webhome
httpRequest.getServerName(); // = mybox.my (1)
httpRequest.getRemoteHost(); // = 10.149.93.49 (2)
httpRequest.getRemoteAddr(); // = 10.149.93.49
httpRequest.getRemoteUser(); // = null ... (3)
N.B.
If you perform a RequestDispatcher.forward() then all the above methods will reflect the new forwarded values. Personally I didn't think the javadocs made this clear.
As of Servlet spec 2.4 however you can still access the original client request data using the following attributes. (see http://www.javaworld.com/javaworld/jw-03-2003/jw-0328-servlet_p.html)
javax.servlet.forward.request_urijavax.servlet.forward.context_pathjavax.servlet.forward.servlet_pathjavax.servlet.forward.path_infojavax.servlet.forward.query_string
Inside a forwarded servlet you'll see getRequestURI() return the path to the target servlet as always, but now if you want the original path, you can call request.getAttribute("javax.servlet.forward.request_uri"). One special caveat: if forward() happens through a getNamedDispatcher() call, these attributes aren't set because, in that case, the original path elements aren't changed.
Note from servlet spec 2.2 there already exists
javax.servlet.include.request_urijavax.servlet.include.context_pathjavax.servlet.include.servlet_pathjavax.servlet.include.path_infojavax.servlet.include.query_string
However, these work just the opposite of the forward() attributes. In an include(), the path elements don't change, so the include attributes act as the backdoor to access the target servlet's path elements. Compare this with a forward() where the path elements change so the forward attributes represent the backdoor to the original path elements.Should filters invoke for forwarded requests? Included requests? What about for URIs invoked via the REQUEST, FORWARD, INCLUDE, and ERROR. You can add any number of
<filter-mapping>
<filter-name>Logging Filter</filter-name>
<url-pattern>/products/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
This indicates the filter should be applied to requests directly from the client as well as forward requests. Adding the INCLUDE and ERROR values also indicates that the filter should additionally be applied for include requests and REQUEST.
The last RequestDispatcher change is to allow, for the first time, relative paths in request.getRequestDispatcher() calls. The path will be interpreted relative to the current request's path. It's a minor change, but comes in handy when dispatching to a sibling servlet.
Notes:
No all these method are available on the basic ServletRequest. Normally I just cast the basic ServletRequest into a HttpServletRequest, since I am normally only writting web apps.
1/ This is the server name from the Request. You can set up your web server to be multi hosted using virtual hosts. (
Heres an example for tomcat). Then you can use this variable to differentiate on which host they came in on. We are using this for setting the locale on one project. (In general it is better to choose the locale based on the request,but we have specific reasons for doing it this way).
2/ This is the clients IP address. Can be used for logging.
3/I'm guess this will show a value if the page is protected by HttpAuthentication.
For Php equivilents check out this page
http://www.php.net/reserved.variables
