Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Response comes with transfer-encoding chunked.
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 / joakim@xxxxxxxxxxx

On Thu, Oct 12, 2017 at 9:20 AM, rajiv <rajivmampuzha@xxxxxxxxx> 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 <joakim@xxxxxxxxxxx> 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.


Joakim Erdfelt / joakim@xxxxxxxxxxx

On Thu, Oct 12, 2017 at 7:35 AM, rajiv <rajivmampuzha@xxxxxxxxx> 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.getDataStream());

        //MANIPLATING THE responseContent
        
        response.getOutputStream().write(responseContent.getBytes());
    }

    @Override
    public void destroy() {}
}

Thanks
Rajiv

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



Back to the top