CODEWITHSUNDEEP
javaspringjspspring-mvc
mahesh
mahesh

Reputation: 4763

net::ERR_INCOMPLETE_CHUNKED_ENCODING SPRING MVC application using JSP

I have developed a web application using SPRING MVC and JSP, now these applications work perfectly fine locally, but when I deployed on the server I am receiving this error. And nothing gets loaded.

This happens with all the page, except login page. Only login page gets displayed successfully. I have monitored the tomcat logs, but no exception there.

Googled whole day but still not able to figure out the root cause for that, please suggest me if you know about this.

chorome network info, show status faul

Upvotes: 11

Views: 15061

Answers (4)

Phil Nguyen
Phil Nguyen

Reputation: 23

In my case, this issue happens because of a proxy that also responds to the header Transfer-Encoding, and my server forwards all the headers to the client side. Removing Transfer-Encoding fixed the issue for me. This has also address here: rfc9112#name-transfer-encoding

HttpHeaders headers = new HttpHeaders();
proxyResonse.getHeaders().forEach((key, value) -> {
    if (!key.equals(HttpHeaders.TRANSFER_ENCODING)) {
       headers.addAll(key, value);
    }
});
// add `headers` to client response

Upvotes: 0

J Smith
J Smith

Reputation: 147

I was able to resolve a similar issue by adding the autoflush attribute to what was suggested by arober11

<%@page buffer="8192kb" autoFlush="true" %>

Upvotes: -1

PA Lemire
PA Lemire

Reputation: 491

I faced this ERR_INCOMPLETE_CHUNKED_ENCODING issue specifically with POST requests handled in the context of a proxy: requests were initiated from the Chrome browser, reaching my SpringMVC-Apache/Tomcat7 webapp, then forwarded to a SpringMVC-Apache/Tomcat8 REST app.

It turns out the root cause was the following: From the proxy, I returned the response to the browser without resetting the HTTP response headers obtained from REST app. So probably Chrome did not like something from those headers.

The solution was to instanciate new response headers from my proxy, while reusing the body received from the REST app.

        ResponseEntity<InfoBean> resE = restTemplate.exchange(reqE, InfoBean.class);
        ResponseEntity<InfoBean> resEE = new ResponseEntity<>(resE.getBody(), HttpStatus.OK);
        return resEE;

Upvotes: 1

arober11
arober11

Reputation: 2019

The remote Tomcat could possibly have a smaller default write buffer size, direct buffer partially configured, or more likely the server may just may have more data it wants to return in a request.

Anyway to see what the values are, temporarily, stick the following tag at the bottom of the body of your login pages JSP, and one broken page.

<% out.println("<p>bufferSize: " + out.getBufferSize() + " remaining: " + out.getRemaining() + " used: " + (out.getBufferSize() - out.getRemaining()) + " autoFlush: " + out.isAutoFlush() + "</p><br>"); %>

You should see something like:

bufferSize: 8192 remaining: 1509 used: 6683 autoFlush: true

As a potential quick fix, see if the non working page will render with no buffer, by say sticking the following tag at the top of JSP page:

<%@ page buffer="none" %>

If still no luck pick a large number, say 8MB (vs 8KB), and see if that's enough for your page to render, by adding a:

<%@ page buffer="8192kb" %>

If that solves the issue, then simply note the used bufferSize on page, add a bit and tweak, so for:

bufferSize: 8380416 remaining: 8321883 used:58533 autoFlush: true

You'd probably get away with:

<%@ page buffer="64kb" %>

If still no luck I suspect you have a broken loop in your JSP.

Note: Don't leave the page buffer at a silly number, as there's a single pool that's shared between all connections.

Upvotes: 11

Related Questions