Spring Framework
  1. Spring Framework
  2. SPR-9791

RestTemplate fails to correctly parse some HTTP URI parameters

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.1.2
    • Fix Version/s: 3.1.3, 3.2 RC1
    • Component/s: Web
    • Labels:
      None

      Description

      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)

        Issue Links

          Activity

          Hide
          Rossen Stoyanchev added a comment -

          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}

          .

          Show
          Rossen Stoyanchev added a comment - 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} .
          Hide
          Eugen Paraschiv added a comment -

          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.

          Show
          Eugen Paraschiv added a comment - 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.
          Hide
          Rossen Stoyanchev added a comment -

          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.

          Show
          Rossen Stoyanchev added a comment - 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.
          Hide
          Rossen Stoyanchev added a comment -

          This issue should now be fixed. See comment under SPR-9832.

          Show
          Rossen Stoyanchev added a comment - This issue should now be fixed. See comment under SPR-9832 .

            People

            • Assignee:
              Rossen Stoyanchev
              Reporter:
              Eugen Paraschiv
              Last updater:
              Chris Beams
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 26 weeks, 2 days ago