jersey
  1. jersey
  2. JERSEY-2127

apache-connector always uses chunked encoding

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.17
    • Fix Version/s: None
    • Component/s: extensions
    • Labels:
      None
    • Environment:

      jersey-core-1.17.1
      jersey-apache-client4
      dropwizard-0.6.2

      Description

      Even with setChunkedEncodingSize(null) an ApacheHttpClient4 will always gerenate chunked encoding. This can annoy some simpler webservers like lighttpd mightily:

      23:05:20.279 [main] INFO  com.example.dw.clienttest.Main - Requesting http://127.0.0.1:8000/ with com.sun.jersey.client.apache4.ApacheHttpClient4...
      23:05:20.604 [main] DEBUG org.apache.http.wire -  >> "POST / HTTP/1.1[\r][\n]"
      23:05:20.605 [main] DEBUG org.apache.http.wire -  >> "Content-Type: application/json[\r][\n]"
      23:05:20.605 [main] DEBUG org.apache.http.wire -  >> "Transfer-Encoding: chunked[\r][\n]"
      23:05:20.605 [main] DEBUG org.apache.http.wire -  >> "Host: 127.0.0.1:8000[\r][\n]"
      23:05:20.605 [main] DEBUG org.apache.http.wire -  >> "Connection: Keep-Alive[\r][\n]"
      23:05:20.605 [main] DEBUG org.apache.http.wire -  >> "User-Agent: Apache-HttpClient/4.3 (java 1.5)[\r][\n]"
      23:05:20.605 [main] DEBUG org.apache.http.wire -  >> "[\r][\n]"
      23:05:20.721 [main] DEBUG org.apache.http.wire -  >> "2[\r][\n]"
      23:05:20.721 [main] DEBUG org.apache.http.wire -  >> "{}"
      23:05:20.721 [main] DEBUG org.apache.http.wire -  >> "[\r][\n]"
      23:05:20.722 [main] DEBUG org.apache.http.wire -  >> "0[\r][\n]"
      23:05:20.722 [main] DEBUG org.apache.http.wire -  >> "[\r][\n]"
      23:05:20.722 [main] DEBUG org.apache.http.wire -  << "HTTP/1.1 411 Length Required[\r][\n]"
      23:05:20.724 [main] DEBUG org.apache.http.wire -  << "Content-Type: text/html[\r][\n]"
      23:05:20.724 [main] DEBUG org.apache.http.wire -  << "Content-Length: 357[\r][\n]"
      23:05:20.724 [main] DEBUG org.apache.http.wire -  << "Connection: close[\r][\n]"
      23:05:20.724 [main] DEBUG org.apache.http.wire -  << "Date: Thu, 03 Oct 2013 21:05:20 GMT[\r][\n]"
      23:05:20.724 [main] DEBUG org.apache.http.wire -  << "Server: lighttpd/1.4.28[\r][\n]"
      23:05:20.724 [main] DEBUG org.apache.http.wire -  << "[\r][\n]"
      

      The output above was generated by the following testcase:

      package com.example.dw.clienttest;
      
      import java.util.HashMap;
      
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      import com.sun.jersey.api.client.Client;
      import com.sun.jersey.api.client.WebResource;
      import com.sun.jersey.client.apache4.ApacheHttpClient4;
      
      public class Main {
          private final static Logger LOGGER = LoggerFactory.getLogger(Main.class);
      	
          private final static String URL = "http://127.0.0.1:8000/";
      	
          public static void main(String[] args) throws Exception {
              Client client = new ApacheHttpClient4();
              LOGGER.info("Requesting {} with {}...", URL, client.getClass().getName());
      		
              client.setChunkedEncodingSize(null);
          	
              WebResource.Builder builder = client.resource(URL)
                      .type("application/json")
          	        .entity(new HashMap<String, Object>());
              builder.post();
          }
      }
      

      The problem is that even though in ApacheHttpClient4Handler.getHttpEntity(ClientRequest) a BufferedHttpEntity is created if the property PROPERTY_CHUNKED_ENCODING_SIZE is set to null, the BufferedHttpEntity will never buffer the contents because it uses EntityUtils.toByteArray(HttpEntity) internally which requests the data from HttpEntity.getContent(). Which returns null.

      I first stumbled upon this issue in a Dropwizard project and originally filed it with Dropwizard as issue 403.

      I'll attach a patch which adds a simple implementation for the getContent() method and fixes up the issue for me.

        Activity

        Hide
        Malte S. Stretz added a comment -

        Sorry, please close this issue, I wanted to use the clone feature to create an issue against 2.x as well but don't have proper permissions.

        Show
        Malte S. Stretz added a comment - Sorry, please close this issue, I wanted to use the clone feature to create an issue against 2.x as well but don't have proper permissions.
        Hide
        Jakub Podlesak added a comment -

        Resolving as invalid as per the user request above.

        Show
        Jakub Podlesak added a comment - Resolving as invalid as per the user request above.

          People

          • Assignee:
            Unassigned
            Reporter:
            Malte S. Stretz
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: