ClassPathResource.isReadable() returns true for directory in runnable jar result in download empty file [SPR-16832]

[spring-projects-issues]

Zhenbang Wei opened SPR-16832 and commented

1. create a spring boot 2.0 project with web module
2. create a directory src/main/resources/static/hello
3. build a runnable jar and run it
4. open http://localhost:8080/hello
5. an empty file is downloaded instead of 404

This is because AbstractFileResolvingResource.isReadable() always returns true and ClassPathResource doesn't override isReadable().

---

Affects: 4.3.17, 5.0.6

Issue Links:

• java.nio.file.Path support in FileSystemResource (with regular createRelative behavior, superseding PathResource) [SPR-16833] #21373 java.nio.file.Path support in FileSystemResource (with regular createRelative behavior, superseding PathResource)

[spring-projects-issues]

Stéphane Nicoll commented

Thanks for the report but Spring Boot issues aren't handled here. I've created #13198, please subscribe to it if we have further questions.

[spring-projects-issues]

Stéphane Nicoll commented

The description made me think it's a Spring Boot problem but it looks like a core framework issue indeed.

[spring-projects-issues]

Andy Wilkinson commented

This looks like a Framework issue to me too. isReadable() will return true for any URL that isn't a file: URL as long as it doesn't throw an IOException. A plain MVC app deployed as a war file will also be affected if static resources are located in a jar in WEB-INF/lib for example.

[spring-projects-issues]

Juergen Hoeller commented

Does this effect show up in Spring Framework 4.3 / Boot 1.5 as well? Or is it exclusive to 5.0?

[spring-projects-issues]

Zhenbang Wei commented

This affects Spring Framework 4.3 / Boot 1.5 as well.

[spring-projects-issues]

Stéphane Nicoll commented

Juergen Hoeller it does though I have to create a dummy file in that directory for it to be shipped in the jar.

[spring-projects-issues]

Juergen Hoeller commented

This is surprisingly hard to determine: The directory nature of such a path within a jar only reveals itself through an NPE on InputStream.close()... a long-standing JDK bug: https://bugs.openjdk.java.net/browse/JDK-8080094. No other regular code path clearly indicates a jar directory path that doesn't end with a slash (like in our case here), as far as I can see at the moment.

We could check for content length >0 but that would turn actual empty files into a 404 as well. Or should we enforce a file extension for 0-length files since they are otherwise definitely not valid content?

[spring-projects-issues]

Juergen Hoeller commented

I'm turning this into a 5.1 only revision since a complete fix incurs quite a bit of overhead in isReadable(), checking the URLConnection for its content length and trying getInputStream().close() in case of length 0: The current JDK implementation throws a NullPointerException from close() while a proper fix is expected to lead to an IOException from getInputStream(), both of which are covered by our catch (Exception) clause that considers the resource as non-readable now.

As for the extra overhead, with the now more extensive implementation of isReadable() in AbstractFileResolvingResource, the contract can be refined for isReadable() to formally imply exists() semantics. This allows our PathResourceResolver and similar clients to replace resource.exists() && resource.isReadable() checks with a plain resource.isReadable() check, avoiding double opening of the file or jar entry underneath, making up for the extra overhead of directory detection through a streamlined check there.

[spring-projects-issues]

Juergen Hoeller commented

Looks like the NullPointerException from close() is not reliable enough... I'm inclined to consider content length 0 as generally not readable now since this is arguably not valid content, even in a web scenario. Either way, implementing this is trickier than expected... but we'll nevertheless try to sort it out in the 5.1 timeframe.