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

Creating relative resource for URL resource should create relative Resource even if relative path has URL in it #28522

Closed
filiphr opened this issue May 25, 2022 · 1 comment
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@filiphr
Copy link
Contributor

filiphr commented May 25, 2022

Affects: 5.3.19 (most likely any version)

We were using the combination of ResourcePatternResolver#getResources and Resource#createRelative for something and received a bug report from a client that doing Resource#createRelative was resolving to an entirely different resource.

e.g.

We have an empty folder named reports on the classpath and if we run the test below it is going to fail because the creation of a relative resource for "http://localhost:8080" will be a resource pointing to that URL and not relative to "classpath*:reports/"

public class UrlResourceTest {

    @Test
    void testRelativeResource() throws IOException {
        PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver();
        for (Resource resource : resolver.getResources("classpath*:reports/")) {
            Resource relative = resource.createRelative("image.png");
            assertThat(relative.getURL().toString())
                    .contains("reports");
            Resource relativeUrl = resource.createRelative("http://localhost:8080");

            assertThat(relativeUrl.getURL().toString())
                    .contains("reports");

        }
    }
}

We realized that in this example the resolved resource for "classpath*:reports/" is a UrlResource and doing createRelative on it will delegate to the JDK new URL(this.url, relativePath).

We were expecting that doing Resource#createRelative will treat the passed relative path as relative, irregardless whether it is a URL, or something else. Were we wrong with our expectations?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label May 25, 2022
@rstoyanchev rstoyanchev added in: web Issues in web modules (web, webmvc, webflux, websocket) in: core Issues in core modules (aop, beans, core, context, expression) labels Feb 9, 2023
@jhoeller
Copy link
Contributor

This is indeed caused by the use of java.net.URL constructors which we intend to get rid of in 6.1 completely: #29481 - since there is heavy use of these facilities all across the Spring ecosystem, we are going to put the changes in place in 6.1 M1 and then go through a milestone phase with them.

For the time being, the best way out is to use StringUtils.applyRelativePath (or similar) for concatenating the paths manually, then building a Resource from them.

@jhoeller jhoeller added type: bug A general bug type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on type: bug A general bug labels Feb 14, 2023
@jhoeller jhoeller self-assigned this Feb 14, 2023
@jhoeller jhoeller added this to the 6.1.0-M1 milestone Feb 14, 2023
@jhoeller jhoeller changed the title Creating relative resource for URL resource does not create relative Resource if relative path has URL in it Creating relative resource for URL resource should create relative Resource even if relative path has URL in it Feb 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants