UriComponents should parse the path of a String URI into path segments [SPR-10959]

[spring-projects-issues]

Jean-Louis Jouannic opened SPR-10959 and commented

Expanding an instance of UriComponents with variable on the path gives different results, depending if it was built from a full String template, or if path segments were appended later.

Here is an example taken from the last comments of issue SPR-8662:

String uri = "http://foo/{bar}";
UriComponents uriComponents = UriComponentsBuilder.fromUriString(uri).build();
System.out.println(uriComponents.expand("user/name").encode().toUriString());

produces

http://foo/user/name

whereas

String uri = "http://foo";
UriComponents uriComponents = UriComponentsBuilder.fromUriString(uri).pathSegment("{bar}").build();
System.out.println(uriComponents.expand("user/name").encode().toUriString());

produces

http://foo/user%2Fname

---

Affects: 3.2.4

Issue Links:

• Provide option in RestTemplate to encode slash in URI variables [SPR-12750] #17347 Provide option in RestTemplate to encode slash in URI variables

[spring-projects-issues]

Rossen Stoyanchev commented

On taking a closer look this is by design. In other words when providing a path, for example via UriComponentsBuilder.path(String), the rules for path encoding apply where "/" is a valid separator char. When providing path segments, for example via UriComponentsBuilder.pathSegment(String), the rules for path segment encoding apply where "/" is a special character that needs encoding.

To look at it from another perspective both are valid use cases. I.e. sometimes you may want to expand a path dynamically and in other cases you may want to expand a variable with a path segment.

[spring-projects-issues]

Jean-Louis Jouannic commented

Actually, I see to different use cases:

• I want separator char "/" to be encoded when path is expanded.
• I want separator char "/" to be preserved when path is expanded.

Am I wrong when I say choosing one way or the other should be done during Uricomponents expanding? Instead, one has to pay attention the way the UriComponent is built.

For example, if I have a "full" URI String template and I still want to obtain encoded "/" in substituted path variables, the only way to do it (or at least the only one I found) is the following:

String uri = "http://foo/{bar}";
UriComponentsBuilder builder = UriComponentsBuilder.fromUriString(uri);
UriComponents tempUriComponents = builder.build();
String[] pathSegments = tempUriComponents.getPath().split("/");
builder.replacePath("");
UriComponents uriComponents = builder.pathSegment(pathSegments).build();
System.out.println(uriComponents.expand("user/name").encode().toUriString());

[spring-projects-issues]

Rossen Stoyanchev commented

Am I wrong when I say choosing one way or the other should be done during Uricomponents expanding? Instead, one has to pay attention the way the UriComponent is built.

Well, expanding applies to all URI variables not just the path so it's not the best place to provide an API option.

UriComponentsBuilder by the way was indeed designed to take notice of whether the path is build with path(String) or pathSegment(String) and to apply encoding accordingly, so yes this is by design. However I do see your point that there is more work when you start with an existing URI template and want to treat the path as path segments.

Perhaps we could provide an additional method to break the path into segments, something like:

UriComponentsBuilder.fromUriString("http://foo/{bar}").splitPath().buildAndExpand("user/name").encode().toUriString();

/cc Arjen Poutsma

[spring-projects-issues]

Arjen Poutsma commented

The behavior seen in the description is indeed by design.

I think the main problem here is the starting point of the discussion: starting with a String URI. I would argue that building a URI from a String is a bad idea in general, because the parsing is so hard. We do our best by using a couple of quite complicated regexes, but it's by no means foolproof. The best way to construct a URI is by building up the various components individually. It is the only way to be sure the UriComponentsBuilder understands your intent correctly.

Given that, I don't think adding a splitPath method would make things better. It introduces even more regex/tokenization trickery which I think we can do without.

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks Arjen. I guess I'm thinking of cases where starting with a URI string is not by choice, perhaps it is obtained from an external system or retrieved from some storage. As far as I can see, breaking the path down isn't the main issue. After all we treat the extracted path as a full path anyway and therefore respect the "/" delimiters.

The key question is of course what to do when expanding URI variables. Whether to use path or path segment encoding is entirely up to the application. Currently when building a URI, the API makes both options easy -- append via path or via pathSegment to get the desired result. However when starting with a URI string you get a full path and there is no easy option to treat it as path segments instead. This is what I had in mind with splitPath. It gives the application the choice to break it down and treat is as path segment. The method would work as advertised, i.e. split by "/" delimiters, and do nothing more. We can document exactly what it was designed to do. Perhaps there are other ways to provide such an option in the API, this is the one I thought of.

[spring-projects-issues]

Rossen Stoyanchev commented

I think with UriComponentsBuilder (where we parse a String and then expand URI template variables) it would be safe to parse the path upfront into path segments.

[spring-projects-issues]

Rossen Stoyanchev commented

Note that in #17347 we introduced an option that allows the RestTemplate to be used with path segment encoding rules.

In particular see the DefaultUriTemplateHandler class and its initUriComponentsBuilder method that shows how to turn the path into path segments with the existing UriComponentsBuilder support.

In light of the RestTemplate now providing a built-in option and the fact it is quite easy to do with UriComponentsBuilder in general I think we are in good shape for this ticket here.