Chunked transfer encoding is for data of undetermined size. It is more correct, better performant, and much better supported than the fallback of data without a content-length. Historically, this logic for chunked encoding has existed since Jetty 4.2.9 (I know, this surprised me too, but google backs me up on this)
If the servlet doesn't give a Content-Length and just starts to write content out via either the HtttpServletResponse.getOutputStream() or HttpServletResponse.getWriter() then the HTTP response is chunked. As for disabling chunked encoding, to do that, you must provide the content length via HttpServletResponse.setContentLength(long), before you access the HttpServletResponse.getOutputStream() and HttpServletResponse.getWriter(). -- Joakim Erdfelt <[email protected]> webtide.com <http://www.webtide.com/> Developer advice, services and support from the Jetty & CometD experts eclipse.org/jetty - cometd.org On Tue, Feb 26, 2013 at 1:57 AM, Nahshon Una - Tsameret <[email protected]>wrote: > Hi all. > > Recently I moved from embedded jetty version 7.2.2 to 8.1.7 > > In the previous version, the responses was sent by jetty > with Content-Length header. In the new version, all the responses are sent > using the chunked transfer encoding. All my responses are single chunk. > > The problem is that the client is a bit limited and does not handle the > chunked transfer encoding properly. > > I would like to ask: > > 1. was this change done on purpose? Is it a good practice to use chunked > transfer encoding for single chunks? what are the advantages? > > 2. How can I disable the chunked transfer encoding, if needed? > > Thanks! > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
