RestTemplate fails to correctly parse some HTTP URI parameters [SPR-9791]

[spring-projects-issues]

Eugen Paraschiv opened SPR-9791 and commented

For the following (non-standard but not prohibited) usage of parameters in an URI:
http://localhost:8080/rest-sec/api/privilege?q=name=value
Where the parameter should be (and indeed, both the browser as well as other libraries to parse it correctly like this):
name = q
value = name=jDiedXRD

Instead of identifying the one parameter, RestTemplate incorrectly identifies two:
q=name
value=null
This happens regardless of the fact that there isn't even a & delimiter in the entire URI.

This is because HttpUrlTemplate is used to parse the URI into UriComponents:
UriComponentsBuilder.fromUriString(uriTemplate).build();
This essentially fails to properly break out the parameter the regex.

Note: escaping the = character before using the template doesn't work either - the template escapes the entire URI again - which results in an invalid URI)

---

Affects: 3.1.2

Reference URL: http://forum.springsource.org/showthread.php?129138-Possible-bug-in-RestTemplate-double-checking-before-opening-a-JIRA&p=421494

Issue Links:

• Erroneous "0" returned where empty string expected in call through the RestTemplate [SPR-9832] #14465 Erroneous "0" returned where empty string expected in call through the RestTemplate ("duplicates")

[spring-projects-issues]

Rossen Stoyanchev commented

When parameter values contain reserved characters, parsing them is ambiguous and not something to rely on. To remove ambiguity, use a URI template variable: http://localhost:8080/rest-sec/api/privilege?q={q}.

[spring-projects-issues]

Eugen Paraschiv commented

Thanks for the feedback. The problem with creating the URI differently is this: the issue itself is not related to what URI is passed into RestTemplate (weather that is created by hand, or via an URI template), but rather that, once the URI is passed into RestTemplate, that internally breaks it down incorrectly, and hence the request itself is done incorrectly.

[spring-projects-issues]

Rossen Stoyanchev commented

That was my point that it's not possible to break it down correctly when reserved characters are present. For example "q=a=b&c=d", q could be "a=b" or "a=b&c=d". If you use URI variable, the ambiguity is resolved, i.e. "q={qValue}" where qValue can contain reserved characters.

[spring-projects-issues]

Rossen Stoyanchev commented

This issue should now be fixed. See comment under #14465.