Allow disabling HTTP range support [SPR-13660]

[spring-projects-issues]

Kevin McLaughlin opened SPR-13660 and commented

Follow up from #15431.

There should be a way to easily disable Range support in ResourceHttpRequestHandler.

https://tools.ietf.org/html/rfc7233

Filter we are using to do this (ugly):

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws
            IOException, ServletException {

        HttpServletResponse httpResponse = (HttpServletResponse) response;
        HttpServletRequest httpRequest = (HttpServletRequest) request;

        httpResponse.setHeader(HttpHeaders.ACCEPT_RANGES, "none");

        // Wrapped response which ignores requests to set Accept-Ranges header.
        HttpServletResponse wrappedResponse = new HttpServletResponseWrapper(httpResponse) {
            @Override
            public void setHeader(String name, String value) {
                if (!HttpHeaders.ACCEPT_RANGES.equals(name)) {
                    super.setHeader(name, value);
                } else {
                    log.trace("Ignoring attempt to set {} to {}", name, value);
                }
            }
        };

        // Wrapped request which hides Range header so Spring doesn't try to fulfill a Range
        // request.
        HttpServletRequest wrappedRequest = new HttpServletRequestWrapper(httpRequest) {
            /**
             * See ResourceHttpRequestHandler.java in spring.  This could break if the condition checking
             * if this header exists changes to use a different method on request.
             */
            @Override
            public String getHeader(String name) {
                return HttpHeaders.RANGE.equals(name) ? null : super.getHeader(name);
            }
        };

        chain.doFilter(wrappedRequest, wrappedResponse);
    }

---

Affects: 4.2.2

Issue Links:

• Add support for http byte-range requests [SPR-10805] #15431 Add support for http byte-range requests
• HTTP Range requests hang on large file in nested jar [SPR-13661] #18236 HTTP Range requests hang on large file in nested jar

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks, could you also elaborate a bit on the issue leading to the request?

[spring-projects-issues]

Kevin McLaughlin commented

Sure.

Chrome (at least):

1. Have large file in nested jar in exe boot jar (see sample boot app in HTTP Range requests hang on large file in nested jar [SPR-13661] #18236 for example).
2. Make normal GET (non-range) request
3. Hit reload before full file is delivered (breaks the transfer).
4. Chrome will then send a single byte range request (https://code.google.com/p/chromium/issues/detail?id=440904). You can see this request in chrome developer tools. Request will show failed and there will be a content length mismatch error in the browser console, though, this request actually works (I think).
5. Chrome then sends the next (remaining bytes) range request which fails. You can't see this request in developer tools, but, if you look in net-internals, you can see it (this took awhile to find). https://dev.chromium.org/for-testers/providing-network-details.

Having discovered #5, I tried that same range request with curl, and that is when it hangs. Though, for some (not figured out) reason, chrome seems to fail the request pretty quickly.

[spring-projects-issues]

Brian Clozel commented

Kevin McLaughlin

Could you elaborate a bit on this? What's the main driver for this feature flag?

• there are cases where you really don't want your application to support range requests?
• or is this strictly related to HTTP Range requests hang on large file in nested jar [SPR-13661] #18236 and you were looking for an escape hatch?

Thanks!

[spring-projects-issues]

Kevin McLaughlin commented

Escape hatch. I haven't had a chance to try the fix in #18236. Will try to today. If it works, then, I am fine w/ closing this wont-fix if you'd rather not add the toggle.

[spring-projects-issues]

Brian Clozel commented

Thanks Kevin McLaughlin,

I'm closing this for now as I don't feel like this configuration flag should be exposed as a first class citizen in the MVC configuration; making it hard to reach won't really help either.

If developers share interesting, valuable use cases for this, we'll reopen this issue and address this.

Thanks!