Question

(See related question: How do I report an error midway through a chunked http repsonse without closing the connection?)

In my case, the #1 desire is for the browser to display an error message. No matter how uninformative.

Closing the ServletResponse outputStream obviously doesn’t work. Neither does throwing an exception, even if I don’t close first (tested on Tomcat 6.0.16). I think that what I want is either a RST packet, FIN in the middle of a chunk, or badly formed chunk headers.

After that I can worry about how various browsers respond.

Edited for clarification: This is for a file download, perhaps several gigabytes of binary data. I can’t make certain that all of the data can be successfully read or decrypted before I have to start sending some of it.

Answer 1

My own answer, after research.

Part one: There seems to be no way to convince the application servers that I tested to put an error onto the wire past the ‘committed’ phase. The following Servlet code results in legal HTTP Chunked Transfer headers on the socket. Interestingly, in the case of WebSphere an error message is appended to the end of the stream before the end mark.

public class Servlet extends HttpServlet {     public static final int ARRAY_SIZE = 65536;     private static final int SEND_COUNT = 100000;      protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException {          String testData = 'This is a fairly long piece of test text, running on and on and on, over and over.';          final ServletOutputStream outputStream = response.getOutputStream();         for (int i = 0; i < SEND_COUNT; ++i) {             outputStream.println(testData);         }         throw new ServletException('Break it now');     } } 

Part two: Even if the application server was willing to either write bogus data to the wire or close the socket without a closing zero length chunk, common clients do not report an error. IE7, FF3 and cURL do not report errors in chunk encoding. This makes HTTP downloads inherently unreliable, and is contrary to the spirit if not the letter of the HTTP 1.1 RFC.