In-depth Analysis of getRequestURI vs getPathInfo Methods in HttpServletRequest

Core Concept Analysis

In Java Servlet programming, the HttpServletRequest interface provides multiple methods for retrieving request path information, among which getRequestURI() and getPathInfo() are the most frequently confused. Understanding their fundamental differences is crucial for building efficient front controllers.

Method Function Comparison

The getRequestURI() method returns the complete request URI, including the context path, Servlet path, and any additional path information. This method returns the raw, URL-encoded string, preserving encoded characters in the URL. For example, for a request to /app/foo/path/to/resource, where /app is the context path and /foo is the Servlet mapping path, this method will return the complete /app/foo/path/to/resource.

In contrast, the getPathInfo() method specifically returns the portion after the Servlet path, i.e., the additional path information. This method returns a URL-decoded string, allowing developers to directly process readable path information. In the same request example, if the Servlet is mapped to /foo, then getPathInfo() will return /path/to/resource.

Code Example Demonstration

To better understand the actual behavior of these two methods, let's demonstrate their differences through a concrete code example:

@WebServlet("/example/*")
public class PathExampleServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) {
        // Get complete request URI
        String requestURI = request.getRequestURI();
        // Get additional path information
        String pathInfo = request.getPathInfo();
        
        // Assuming request URL: http://localhost:8080/app/example/users/123
        // Context path: /app
        // Servlet mapping: /example/*
        
        // requestURI will return: /app/example/users/123
        // pathInfo will return: /users/123
        
        System.out.println("Request URI: " + requestURI);
        System.out.println("Path Info: " + pathInfo);
    }
}

Impact of Servlet Mapping

Servlet mapping configuration directly affects the return value of getPathInfo(). When a Servlet uses exact matching (such as /foo) or extension matching (such as *.jsp), getPathInfo() returns null. Only when using path matching (ending with /*) does this method return valid additional path information.

Consider the following mapping configuration examples:

// Mapping 1: Exact matching
@WebServlet("/api")
// For request /api/users, getPathInfo() returns null

// Mapping 2: Path matching
@WebServlet("/api/*")
// For request /api/users, getPathInfo() returns /users

URL Encoding and Decoding Behavior

Another important distinction lies in the handling of URL encoding. getRequestURI() returns the raw encoded string, while getPathInfo() returns the decoded string. This is particularly important when processing paths containing special characters.

For example, for a request path containing encoded spaces /app/test%20space/path:

// getRequestURI() returns: /app/test%20space/path
// getPathInfo() returns: /test space/path (if Servlet mapped as /test*)

Practical Application Scenarios

When building front controllers, the choice of method depends on specific requirements:

1. When to use getPathInfo(): When dealing with RESTful-style URLs, or when routing decisions need to be based on path hierarchy, getPathInfo() provides cleaner, decoded path information that is easier to parse and process.
2. When to use getRequestURI(): When complete request path information is needed, including context path and Servlet path, or when the original encoded state of the URL must be preserved, getRequestURI() should be used.

Special Considerations in Spring MVC

It's worth noting that in the Spring MVC framework, getPathInfo() typically returns null, as Spring uses different mechanisms for request mapping. Spring developers should primarily rely on getServletPath() and framework-provided annotations (such as @RequestMapping) for path matching.

Best Practice Recommendations

Based on the above analysis, we propose the following best practices:

• In custom Servlets or front controllers, prioritize using getPathInfo() for path matching, as it provides cleaner, decoded additional path information.
• Ensure correct Servlet mapping configuration by using path matching (/*) to enable getPathInfo() functionality.
• When processing paths containing special characters, be aware of the differences in URL encoding handling between the two methods.
• In Spring MVC applications, follow framework conventions by using Spring's path handling mechanisms rather than directly relying on Servlet API.

By deeply understanding the core differences between getRequestURI() and getPathInfo(), developers can more effectively design and implement request routing logic, building more robust and maintainable web applications.