UriComponentsBuilder interprets empty request parameters as null [SPR-13537]

[spring-projects-issues]

Sam Brannen opened SPR-13537 and commented

Status Quo

#18101 brought it to our attention that UriComponentsBuilder returns null for empty request parameters instead of an empty string.

For example, given a request such as http://example.com/login?error, the error request parameter is empty but still present in the query string. Thus we would expect UriComponentsBuilder to store its value as an empty string; however, UriComponentsBuilder currently stores it in its query map as null.

This is contrast to Spring MVC's support for @RequestParameter. When using @RequestParameter in a controller handler method, Spring always passes in an empty string for an empty request parameter value, regardless of whether the = sign is present in the query string.

Analysis

The source of this behavior is in UriComponentsBuilder.query(String), specifically in this line:

queryParam(name, (value != null ? value : (StringUtils.hasLength(eq) ? "" : null)));

For empty request parameter values, if the = sign is present, the value is set to an empty string ""; otherwise, the value is set to null.

Furthermore, similar logic exists in UriComponentsBuilder.queryParam(String, Object...): queryParam(...) stores null instead of an empty string for an empty value.

Deliverables

1. Ensure that UriComponentsBuilder stores empty request parameters as empty strings.
   • Updated both query(String) and queryParam(String, Object...)
   • See TODO in UriComponentsBuilderTests.

---

Issue Links:

• HtmlUnitRequestBuilder doesn't handle query parameters without equals sign [SPR-13524] #18101 HtmlUnitRequestBuilder doesn't handle query parameters without equals sign
• Using the MvcUriComponentsBuilder to get a URL to a controller method adds empty parameter when the value is not provided [SPR-14890] #19456 Using the MvcUriComponentsBuilder to get a URL to a controller method adds empty parameter when the value is not provided

Referenced from: commits c52f9d3

[spring-projects-issues]

Rossen Stoyanchev commented

Resolving in favor of the existing behavior which preserves the distinction between empty value and value-less query parameters. It is conceivable that servers may have slightly different semantics for that.

Note that the UriTemplateHandler introduced in 4.2 could be used to change this behavior where usage of the RestTemplate is concerned at least.

[spring-projects-issues]

Rafal Sykala commented

Hi @rstoyanchev , I have to disagree, because current behavior causes inconsistency in code dealing with URIs.
I've come across this when investigating inability to match URI defined as in the description (http://example.com/path?param) when using spring-test.
It is supposed to match @RequestMapping(path="/path", params="param")
and it works like a charm in runtime (Tomcat) but fails to resolve when using MockMvc.

The reason is that MockHttpServletRequest uses UriComponentsBuilder to parse the URI which results having value of param set to null, whereas HttpServletRequest parses the value as an empty string.
Handler mapping infrastructure relies rather on behavior of HttpServletRequest, that is, org.springframework.web.servlet.mvc.condition.ParamsRequestCondition which is responsible for handling params of @RequestMapping, matches only if the param's value is not null.
It uses org.springframework.web.util.WebUtils#hasSubmitParameter for that purpose which makes a valid assumption from servlet and RFC perspective.

If changing behavior of UriComponentsBuilder is not acceptable, maybe MockHttpServletRequest could use modified logic to better match runtime HttpServletRequest behavior?
Regardless of the resolution I think it would be beneficial to have test infrastructure following runtime behavior and have spring-test being able to run valid runtime scenarios.

Please share your thoughts on that.

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.