1. Axis2
  2. AXIS2-4318

Upgrade CommonsHTTPTransportSender to use httpclient 4.0


    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.1
    • Fix Version/s: 1.7.0
    • Component/s: None
    • Labels:


      3 areas currently using commons-httpclient 3.1:

      1. The code that interfaces between Axis2 and the underlying
      transport, e.g. the Stub class. This code only refers to
      org.apache.commons.httpclient.Header and could easily be made
      independent of commons-httpclient. This is what the patch in
      AXIS2-3933 does.

      2. MultipartFormDataFormatter uses code from commons-httpclient to
      build multipart/form-data requests. Maybe this code should be
      rewritten to use HttpMime [1] and/or mime4j.

      3. The code in the HTTP transport. Note that in Axis2 1.5 this code is
      no longer part of the kernel and lives in a separate module. The core
      question here is whether we should upgrade that code from
      commons-httpclient 3.1 to HttpClient 4.0 or if it is better to keep
      two separate transport sender implementations (at least temporarily).
      It would be interesting to get Oleg's opinion on this.

      For the legal issue around NTLM, I think the best solution is to allow
      the user to register additional AuthSchemeFactory classes in the
      transport configuration in axis2.xml. People who need NTLM can than
      use the code from [2].


      I am willing to provide a patch to upgrade to httpclient 4.0. I have completed some work locally and I believe most of the existing functionality has been replicated successfully in httpclient 4.0 but still more areas need to be settled before the local work becomes a candidate for commit into the trunk.

      Unanswered questions/proposals:

      1) I assume upgrading to httpclient 4.0 rather than providing a separate transport is the best long term solution.

      2) Drop support for HTTPConstants.CUSTOM_PROTOCOL_HANDLER option

      Reason DefaultHttpClient already supports http and https schemes by default do we really want to allow a user to use a different scheme/socketfactory combination? This doesn't seem to be a commonly used feature.

      If we still need to support this option then an instance of Scheme would need to be passed in by the user and registered in the SchemeRegistry in turn used to build the HttpClient. We can no longer use a DefaultHttpClient if we do this, we would have to extend it most likely.

      3) drop authenticator preemptive authentication support

      Preemptive authentication is considered unsecure and is strongly discouraged. Moreover the code found in examples: is no longer officially supported. Which means that we should drop preemptive authentication support from the trunk; alternatively we can allow a number of pluggable mechanisms to allow users to enable preemptive auth. The user would have to provide HttpRequestInterceptor and HttpResponseInterceptor implementations as well as a means to properties to configure a BasicHttpContext for use with the HttpClient. As a workaround/alternative the user could fully initialize it's own AbstractHttpClient instance and pass it through the existing CACHED_HTTP_CLIENT option.

      3) Drop support for HTTPConstants.AUTO_RELEASE_CONNECTION

      httpclient 4.0 already releases http connections (to the connection pool) after every http method execution. Therefore this property becomes obsolete.

      4) Axis2 and java compiler source compliance setting? I see that some axis2 modules still compile with 1.4 source compliance. Should this be supported? On mailing lists I saw that Axis2 already started moving to java 5. Should Axis2 1.4 kernel module still use java compliance 1.4, should we change source compliance for the kernel to 1.5?

      1. AXIS2-4318_06.patch
        10 kB
        Kishanthan Thangarajah
      2. AXIS2-4318_05.patch
        5 kB
        Kishanthan Thangarajah
      3. AXIS2-4318_04.patch
        21 kB
        Kishanthan Thangarajah
      4. AXIS2-4318_03.patch
        74 kB
        Kishanthan Thangarajah
      5. AXIS2-4318_02.patch
        8 kB
        Kishanthan Thangarajah
      6. AXIS2-4318_01.patch
        17 kB
        Kishanthan Thangarajah
      7. axis2-1.6.1-patch-for-httpclient4.1-WORK-IN-PROGESS.diff
        108 kB
        Ian Beaumont
      8. workinprogress.patch
        99 kB
        Guillaume Jeudy

        Issue Links



            • Assignee:
              Kishanthan Thangarajah
              Guillaume Jeudy
            • Votes:
              16 Vote for this issue
              19 Start watching this issue


              • Created: