Improve resource handling for empty files contained in jars

[larsgrefer]

We noticed a strange behavior in WebMVC when working with empty files:

We had some empty files in a classpath location configured in org.springframework.web.servlet.config.annotation.WebMvcConfigurer#addResourceHandlers

When running the application locally using the IDE, the files could be "successfully" accessed by the browser (it got a HTTP 200 response with content-length 0)

After packaging the application, the browser suddenly got 404 responses for the empty files.

The difference seems to be in org.springframework.core.io.AbstractFileResolvingResource#checkReadable.
As long as the empty files are actual files on the file system (ResourceUtils.isFileURL(url) == true), the corresponding ClasspathResource is considered both existent and readable.
After packaging into a jar file, the ClasspathResource is still existent, but no longer considered readable.

I know that serving empty files as static resources is not a typical use case, but I think it should still be (a) possible and (b) consistent, regardless of whether the ClasspathResource in question is an actual File or a JarFileEntry

[JanStureNielsen]

It seems like checkReadable should be consistently handling empty-content, or not at all, regardless of packaging, and this inconsistency feels like a bug; so, what motivated the comment "empty file or directory -> not considered readable..."?

If empty-content is okay for ResourceUtils, HttpURLConnection, and JarURLConnection branches, why not okay for the rest?

[bclozel]

Indeed, serving an empty resource over HTTP should not result in a 404 response.

The current behavior can be tracked to #21372, where we tried to avoid serving empty files for directory entries. In the course of fixing that problem (in 69f14a2 and 616a40a), it appeared that a long-standing JVM bug prevents us from considering folders and empty resources separately. @JanStureNielsen this should answer your comment.

This behavior has been in place since Spring Framework 5.1 and we've been reluctant to change things more in this area, because of risks of regression or performance issues. In the meantime, this problem has been reported multiple times in Spring Boot and Spring Framework (see #28107 for the latest instance).

I'm inclined to consider this change, which should solve the JAR case and improve consistency with the file system case. Now we're quite late in the 5.3.x cycle, so maybe pushing this to 6.0.0 would make more sense. What do you think @jhoeller @rstoyanchev ?