HTTP Range requests hang on large file in nested jar [SPR-13661]

[spring-projects-issues]

Kevin McLaughlin opened SPR-13661 and commented

Followup from #15431.

We ended up adding a servlet filter that drops attempts to set ACCEPT_RANGE header.
Sample bootapp showing this issue is at https://github.com/krm1312/springrangeissues. Take that project and:

mvn clean package && java -jar bootapp/target/bootapp.jar

and then try a range request with curl:

curl -vvv -H "Accept-Encoding: gzip"  -H 'Range: bytes=4726785-5726784' http://localhost:8080/test/file.bin > /tmp/f

It effectively hangs.

---

Affects: 4.2.2

Issue Links:

• Allow disabling HTTP range support [SPR-13660] #18235 Allow disabling HTTP range support
• Add support for http byte-range requests [SPR-10805] #15431 Add support for http byte-range requests

Referenced from: commits b35d44b

[spring-projects-issues]

Brian Clozel commented

This has been fixed and should be available shortly on https://repo.spring.io.

I think this problem can only be seen when running a packaged Spring Boot application, so indeed using Spring Boot's ZipInflaterInputStream for reading resources. Serving resources just using Spring Framework does not show the problem.

You can test this fix in your Boot application by configuring it to use the latest SNAPSHOT version of Framework. Note: obviously, I don't think doing this is supported by the Boot team, but rather a simple way to verify the fix if you want to. You can add the following in your POM to do so (along a repository declaration to "repo.spring.io/libs-snapshot"):

<properties>
  <spring.version>4.2.4.BUILD-SNAPSHOT</spring.version>
</properties>

Thanks for this report and this very useful repro project!

[spring-projects-issues]

Kevin McLaughlin commented

Finally had a chance to test this with our real application. Looks good.

Also, as a side note, serving the entire file seems to take about half the time in my unscientific test (time curl) w/ 4.2.4 from localhost. Not sure if that was expected with the fix, but, we'll take it.

Thanks!