Leading slash in template path in controller causes template not found in executable jars

[jedvardsson]

A leading slash in the template path causes a template not found error. For example, in the controller below when sample1 is called Spring will lookup the following resource: classpath:/templates/index.html. In turn this translates to classLoader.getResource("templates/index.html")

@Controller
public class SampleController {

    @RequestMapping("/sample1/")
    public String sample1() {
        return "index.html";
    }

    @RequestMapping("/sample2/")
    public String sample2() {
        return "/index.html";
    }
}

However, when sample2 is called, it translates to classLoader.getResource("templates//index.html") (note the double slash). If index.html resides in a regular directory Java seems to be able to find it (this is the case when running from exploded war in Tomcat). However, when running through an executable jar, the resource is actually contained within a jar file, causing Java not find the resource unless the extra slash is removed.

The work around is of course to remove leading slash from the template path, however, it would be nice if spring handled this gracefully and removed any leading slashes.

Below is JUnit test showing that the double slash causes problems for Java.

package com.example;

import org.junit.Assert;
import org.junit.Ignore;
import org.junit.Test;

import java.net.URI;
import java.net.URISyntaxException;

@Ignore
public class ClassPathTest {

    @SuppressWarnings("ConstantConditions")
    @Test
    public void test() throws URISyntaxException {
        ClassLoader classLoader = getClass().getClassLoader();
        URI fileUri = classLoader.getResource("com/example/ClassPathTest.class").toURI();
        Assert.assertEquals("file", fileUri.getScheme());
        Assert.assertTrue(fileUri.getSchemeSpecificPart().endsWith("com/example/ClassPathTest.class"));

        URI fileUriDoubleSlash = classLoader.getResource("com/example//ClassPathTest.class").toURI();
        Assert.assertTrue(fileUriDoubleSlash.getSchemeSpecificPart().endsWith("com/example//ClassPathTest.class"));


        URI jarUri = classLoader.getResource("java/lang/String.class").toURI();
        Assert.assertEquals("jar", jarUri.getScheme());
        Assert.assertTrue(jarUri.getSchemeSpecificPart().endsWith("rt.jar!/java/lang/String.class"));


        // Throws NullPointerException since getResource returns null!
        URI jarUriDoubleSlash = classLoader.getResource("java/lang//String.class").toURI();
        Assert.assertEquals("jar", jarUriDoubleSlash.getScheme());
        Assert.assertTrue(jarUriDoubleSlash.getSchemeSpecificPart().endsWith("rt.jar!/java/lang//String.class"));
    }
}

[wilkinsona]

I'm not sure there's much we can do about this. As you've observed, it's standard JRE behaviour to fail with // in a resource's path. See also #1744. Doing some processing of the path during view resolution, as I think you're suggesting, would be better tackled in Spring Framework than in Spring Boot.

[jedvardsson]

Thanks, yes I agree it would be better to do it in Spring Framework.

[wilkinsona]

@jedvardsson Could you raise an issue in the Spring Framework JIRA please?

[odrotbohm]

That issue just popped up here. What was the outcome? I couldn't find an issue reported in Spring Framework. @jedvardsson — Did you report an issue? If so, do you have a link?

[php-coder]

I've filled the issue https://jira.spring.io/browse/SPR-15596 but I'm not sure that it's exactly the same as this one.

[TomVerkon]

Leading slash in template path in controller causes template not found in executable jars. Can somebody tell me if this issue was fixed? It is June 20, 2020 and I'm still getting having this issue when I deploy my spring boot app to Heroku.

[wilkinsona]

@TomVerkon No fix was made. As you can see from the Spring Framework issue that is linked to above, a change was considered but rejected over concerns about it creating a possible security exploit.

[TomVerkon]

Thanks for getting back to me. I understand.

…

On Sun, Jun 21, 2020 at 3:34 AM Andy Wilkinson ***@***.***> wrote: @TomVerkon <https://github.com/TomVerkon> No fix was made. As you can see from the Spring Framework issue <spring-projects/spring-framework#20155> that is linked to above, a change was considered but rejected over concerns about it creating a possible security exploit <spring-projects/spring-framework#20155 (comment)> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXLBLLL4S3UKRSXXXBJMULRXWZW5ANCNFSM4BLPOSTA> .