Be more defensive in UrlResource about cleaning the path [SPR-17198]

[spring-projects-issues]

Dave Syer opened SPR-17198 and commented

This method from UrlResource throws UnsupportedFeatureError in GraalVM:

private URL getCleanedUrl(URL originalUrl, String originalPath) {
     try {
          return new URL(StringUtils.cleanPath(originalPath));
     }
     catch (MalformedURLException ex) {
          // Cleaned URL path cannot be converted to URL
          // -> take original URL.
          return originalUrl;
     }
}

So the originalUrl would have been fine, but it cannot get past this private method to read the input stream. We could be more defensive there.

---

Affects: 5.0.8

Reference URL: oracle/graal#623

Issue Links:

• Initial GraalVM native images (Substrate VM) support [SPR-16991] #21529 Initial GraalVM native images (Substrate VM) support ("is depended on by")
• UrlResource getFilename should not contain query parameters [SPR-15411] #19974 UrlResource getFilename should not contain query parameters

[spring-projects-issues]

Dave Syer commented

PR: #1936 (verified to work with Graal AOT).

[spring-projects-issues]

Juergen Hoeller commented

A straightforward refinement for a start is to only create a new URL instance if the cleaned path actually differs from the original path. This should cover most internal use of UrlResource and avoid common Graal issues with it that way.

[spring-projects-issues]

Dave Syer commented

That would also work. I can change the PR if you want.

[spring-projects-issues]

Juergen Hoeller commented

Ha, seems we posted at exactly the same time there ;-) Got the change locally working already, let's see how far we get with it (to be pushed ASAP)... I quite like it as a general optimization, avoiding the repeated URL parsing effort. I was experimenting with handling the cleaned path as a String but unfortunately that causes some regressions due to special handling in URL.equals, so the "original URL as far as possible" approach sounds like the best compromise.