The other day I realized that my Tomcat is using chunked Transfer-Encoding (HTTP 1.1) by default. I don’t know about other servers/containers/frameworks/languages, but it is not uncommon to send pages in chunks – facebook, for example, does it. What “chunked” means is that the server sends pieces of the page that it has already prepared, so that the browser can render them, while the server processes the next chunks.
In JSP (and likely in many other view technologies) there is a buffer – whenever the buffer is filled, it is flushed to the client. This means that all headers are sent, together with the first chunk of information (i.e. the contents of the buffer).
But there’s one caveat – what happens if an error occurs when the server processes the 2nd (or any subsequent) chunk? You may expect your server to send the error page to the browser, but it can’t work that way:
- you can’t redirect (send a Location header), because the headers and the response status were already sent. (You can’t, and of course the server can’t)
- you can’t do server-side redirect (forward), because the new page will have to be rendered after the part that is already sent – it will look ugly for sure
I wondered what to do, and asked this question on stackoverflow. Obviously, there is no good way out of the situation. What I did is send this snippet to the browser which then redirects to the error page:
How this is done in JSP in particular: <%@ page errorPage="/error/redirector.jsp" %>, and redirector.jsp contains the above script tags. Why do we start with a closing script tag? It’s possible that there is an open script tag in the already-rendered chunk, so we have to close it. Ugly, I know, but there appears to be no other way.
Another question arises – do we need chunked encoding here, and isn’t it meant for large files that are downloaded? This is a separate discussion, but since Tomcat uses this as the default Transfer-Encoding, and facebook uses it as well, I wouldn’t say it’s a crime to use it for regular pages.