This problem is related to this issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=50753 The first asynchronous request lets you set the response header, and that response gets parsed correctly on the client side. The following requests in the same async context does not let you set the response headers, and Tomcat seem to give some default headers only. In addition, it also switches to chunked transfer encoding because of missing content length. This results in errors in clients trying to read the response from a Tomcat context. These problems does not occur when using Jetty using the same Servlet 3.0 API's. This problem was discovered while updating the BOSH plugin for the Vysper project: https://issues.apache.org/jira/browse/VYSPER-307 The same problem was observed in both Tomcat version 7.0.25 and 7.0.27.
This bug report does not make sense. There is only ever one request/response per AsyncContext.
Created attachment 28729 [details] Tomcat backend for XMPP connection
Created attachment 28730 [details] Jetty backend for XMPP connection
My original report might not have been too clear. I'll try to clearify a bit. I've added two attachments to this bug, logs that describes how both Jetty and Tomcat handles the same code for handling XMPP requests. First off, with "request" I meant several blocks of communication back and forth between the server and client in the same HTTP request. Using async communication, it is possible to leave the connection open, and let the client and server talk to eachother at any time. Between each communication block, the request is "ended" as a normal request would be, using the content-length header to determine where the request and response ends. This is supported by both Tomcat and Jetty. The difference is that while Jetty correctly hands out the headers you configure every single time, this only works for the first block for Tomcat. The request would work as follows: * Client connects to server to servlet defined with async support * Client sends first request as normal * Server responds with content-length * AsyncContext.dispatch() * Client reads response, leaves connection open * Client sends new "request" in the same manner as last time * Server again responds with content-length * AsyncContext.dispatch() * Client reads response, leaves connection open ... This is how I've understood that this should work, and this is how Jetty currently does it. It might be that I'm wrong, so please correct me.