Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Sep 12, 2012 · 4 comments
Assignees
Labels
in: web type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 12, 2012

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:

  • #14465 Erroneous "0" returned where empty string expected in call through the RestTemplate ("duplicates")
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 3, 2012

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 3, 2012

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 5, 2012

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 22, 2012

Rossen Stoyanchev commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web type: bug
Projects
None yet
Development

No branches or pull requests

2 participants