With HTTP/1.1 the lack of "Connection: close" header on the server (or client) side means that the connection should stay open (aka persistent connections).
The HTTP spec indicates that to support persistent connections, the signal/event indicating the end of the request or end of the response are important. For example: If you have a persistent connection (no "Connection: close"), and a response without a "Content-Length" header this "end of response" event can only be conveyed via a Chunked Transfer Encoding (which sends a trailer indicating that the content is complete) However, if you decide to not use persistent connections by using the "Connection: close" header then event is the actual connection disconnect. But this is inferior to Chunked Transfer Encoding as other parts of the HTTP spec says a connection disconnect can occur at any time, even before the response content has completely been sent, leaving you with no knowledge in the HTTP protocol that the response body was completely sent. Incidentally, HAProxy 1.7+ supports compression of chunked proxy responses. But why do you use HAproxy for compression? Jetty 9 has a very capable compression interceptor for responses? The compression interceptor in Jetty 9 is also capable of cooperating with the ETag / if-modified-since behavior found across Jetty internals (like the DefaultServlet / memory-mapped static file serving / traditional static file serving / and precompressed content behaviors) Joakim Erdfelt / [email protected] On Thu, Oct 12, 2017 at 9:20 AM, rajiv <[email protected]> wrote: > I have a Haproxy doing proxying of my requests and it does gzip of my > response as well. If the response if chunked then Haproxy is not doing > compression. Thats why I don't want chunking. > > So are you saying, if I set explicit content length then this issue will > get resolved? > > It will be great if somebody can explain what is happening in my case > (What difference this filter is doing here?) . Why outputBufferSize > and outputAggregationSize configurations (jetty.xml) are not honored by > jetty? > > Thanks > Rajiv > > > > On Thu, Oct 12, 2017 at 7:42 AM, Joakim Erdfelt <[email protected]> > wrote: > >> Jetty 9.4.0 is getting rather old (and is 2,248 commits behind 9.4.7) >> >> Chunked Transfer-Encoding is required if ... >> >> Your response has no "Content-Length" header >> or your response does not have "Connection: close" header set >> >> So either set the Content-Length to the valid length of your content, or >> set the "Connection: close" >> >> However, the more fundamental question is why Chunked Transfer-Encoding >> is a problem for you? >> That's a required (MUST support) feature of all HTTP clients to be >> considered spec compliant. >> https://tools.ietf.org/html/rfc7230#section-4.1 >> >> >> Joakim Erdfelt / [email protected] >> >> On Thu, Oct 12, 2017 at 7:35 AM, rajiv <[email protected]> wrote: >> >>> Hi All, >>> >>> My application exposes multiple rest services, which is deployed in a >>> jettycontainer (Jettyrunner jetty-9.4.0.v20161208). >>> >>> I don't want my response to be chunked. Hence used attached jetty.xml >>> configuration to increase the output buffer size. It was working without >>> any issue. Suddenly after a release it stopped working and after some >>> investigation we found that we had removed one custom servlet filer from >>> codebase as it is no longer required and hence jetty started chunking the >>> response. >>> >>> This custom filter is used to alter the response. If this filer is there >>> then chunking is stopped and I can see proper content length response >>> header. >>> >>> How can I fix this without a filer? Can anybody explain me what is >>> really happening here? >>> >>> My filter sample code is below. >>> >>> public class ContentFilter implements Filter { >>> @Override >>> public void init(FilterConfig filterConfig) {} >>> >>> @Autowired >>> ContentServiceImpl contentServiceImpl; >>> >>> @Override >>> public void doFilter(ServletRequest request, ServletResponse >>> response, FilterChain chain) throws IOException, ServletException { >>> HttpServletRequest httpRequest = (HttpServletRequest) request; >>> ResponseWrapper responseWrapper = new >>> ResponseWrapper((HttpServletResponse) response); >>> chain.doFilter(request, responseWrapper); >>> String responseContent = new String(responseWrapper.getData >>> Stream()); >>> >>> //MANIPLATING THE responseContent >>> >>> response.getOutputStream().write(responseContent.getBytes()); >>> } >>> >>> @Override >>> public void destroy() {} >>> } >>> >>> Thanks >>> Rajiv >>> >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
