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

URIEditor should not double escape classpath: URIs [SPR-16581] #21123

spring-projects-issues opened this issue Mar 12, 2018 · 1 comment
in: core status: backported type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Mar 12, 2018

Gerhard Bloch opened SPR-16581 and commented

My Tomcat installation has a space character in the path (installation is provided so I cannot change this). I want to configure my EhCache via JCacheManagerFactoryBean, property cacheManagerUri=classpath:ehcache.xml. The resource URL yields something like ...%20... which is the correct encoding of the space character, but then the default URIEncoder (which is "encoding" by default) encodes the percent sign and I end up with a URI like ...%2520... which does not work for obvious reasons. I do not understand why the URIEditor needs to "encode" at all, looks like fixing broken URIs at the wrong place, but at least for the case of classpath: URI's I absolutely do not see a point in applying any additional encoding. The resource gives a valid URL and this is just fine as it is.

I suggest to replace the createURI(url) in URIEditor:110 by a simple new URI(url). Running such patch fixes the issue for me.

Affects: 4.3.14, 5.0.4

Issue Links:

  • #10673 org.springframework.beans.propertyeditors.URIEditor does double escaping for % signes for URIs that contain a schema
  • #11743 Unable to inject a URI with a fragment as a bean property value

Backported to: 4.3.15

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 12, 2018

Juergen Hoeller commented

Good catch, URIEditor is quite outdated there: For classpath URLs, it should use ClassPathResource.getURI() directly, not even going via getURL().toString() and then parsing the String into a URI instance again. The encoding step is only meant to be applied to user-specified values to begin with, not to system-obtained ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core status: backported type: bug
None yet

No branches or pull requests

2 participants