I have a Java Servlet that responds to the Twilio API. It appears that Twilio does not support the chunked transfer that my responses are using. How can I avoid using Transfer-Encoding: chunked?
Here is my code:
// response is HttpServletResponse // xml is a String with XML in it response.getWriter().write(xml); response.getWriter().flush(); I am using Jetty as the Servlet container.
I believe that Jetty will use chunked responses when it doesn't know the response content length and/or it is using persistent connections. To avoid chunking you either need to set the response content length or to avoid persistent connections by setting "Connection":"close" header on the response.
Connection: close suppresses chunking, but then Jersey isn't supplying Content-Length, even though my MessageBodyWriter returns a non-negative getSize. I can set it myself, but then if the response is gzip-encoded, my Content-Length will be wrong and Jersey removes it.Try setting the Content-length before writing to the stream. Don't forget to calculate the amount of bytes according to the correct encoding, e.g.:
final byte[] content = xml.getBytes("UTF-8"); response.setContentLength(content.length); response.setContentType("text/xml"); // or "text/xml; charset=UTF-8" response.setCharacterEncoding("UTF-8"); final OutputStream out = response.getOutputStream(); out.write(content); 
setCharacterEncoding is probably not necessary since you are writing raw bytes. content type should include encoding: "text/xml; charset=UTF-8".The container will decide itself to use Content-Length or Transfer-Encoding basing on the size of data to be written by using Writer or outputStream. If the size of the data is larger than the HttpServletResponse.getBufferSize(), then the response will be trunked. If not, Content-Length will be used.
In your case, just remove the 2nd flushing code will solve your problem.
