Proxy-Authorization header is not send within first request in Apache HttpComponents

Question

I'm using Apache HttpComponents (4.5.2) and I'm trying to request HTTPS page via proxy server (SSH Tunneling).

The problem is that according to logs Client sends first request without Proxy-Authorization header, but after Proxy respond with 407 error (Proxy Authentication Required), it retires authentication with sending Proxy-Authorization header.

I think problem in my code, I need something like enabling primitive auth , but I couldn't find any information about how to do that.

Below is logs for confirming my words.

First request:

03:12:06,643 DEBUG headers:135 - http-outgoing-0 >> CONNECT t.myhost.com:443 HTTP/1.1
03:12:06,643 DEBUG headers:138 - http-outgoing-0 >> Host: t.myhost.com
03:12:06,643 DEBUG headers:138 - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_45)

03:12:06,793 DEBUG headers:124 - http-outgoing-0 << HTTP/1.1 407 Proxy Authentication Required
03:12:06,794 DEBUG headers:127 - http-outgoing-0 << Proxy-Authenticate: Basic realm="ProxyCompany"
03:12:06,794 DEBUG headers:127 - http-outgoing-0 << Proxy-Connection: close

// then it retries request with included Proxy-Authorization header

03:12:06,795 DEBUG HttpAuthenticator:77 - Authentication required
03:12:06,795 DEBUG HttpAuthenticator:107 - 162.243.116.56:71223 requested authentication
03:12:06,795 DEBUG ProxyAuthenticationStrategy:174 - Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, Digest, Basic]
03:12:06,795 DEBUG ProxyAuthenticationStrategy:203 - Challenge for Negotiate authentication scheme not available
03:12:06,796 DEBUG ProxyAuthenticationStrategy:203 - Challenge for Kerberos authentication scheme not available
03:12:06,796 DEBUG ProxyAuthenticationStrategy:203 - Challenge for NTLM authentication scheme not available
03:12:06,796 DEBUG ProxyAuthenticationStrategy:203 - Challenge for Digest authentication scheme not available
03:12:06,800 DEBUG HttpAuthenticator:157 - Selected authentication options: [BASIC [complete=true]]
03:12:06,800 DEBUG DefaultManagedHttpClientConnection:81 - http-outgoing-0: Close connection
03:12:06,801 DEBUG DefaultHttpClientConnectionOperator:138 - Connecting to /162.243.116.56:71223
03:12:06,942 DEBUG DefaultHttpClientConnectionOperator:145 - Connection established 192.168.0.100:13391<->162.243.116.56:71223
03:12:06,942 DEBUG HttpAuthenticator:198 - Generating response to an authentication challenge using basic scheme
03:12:06,947 DEBUG headers:135 - http-outgoing-0 >> CONNECT t.myhost.com:443 HTTP/1.1
03:12:06,947 DEBUG headers:138 - http-outgoing-0 >> Host: t.myhost.com
03:12:06,947 DEBUG headers:138 - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_45)
03:12:06,947 DEBUG headers:138 - http-outgoing-0 >> Proxy-Authorization: Basic bHVtXXXXXXXXXXXXxOTE5NTUXXXXXXRmNmRkYmI1Mjk0MA==

03:12:07,304 DEBUG HttpAuthenticator:86 - Authentication succeeded
03:12:07,305 DEBUG ProxyAuthenticationStrategy:227 - Caching 'basic' auth scheme for http://162.243.116.56:71223 

And this is my code (it's Scala, but pretty easy to read):

val credProvider = {
  val provider = new BasicCredentialsProvider()
  provider.setCredentials(AuthScope.ANY,
    new UsernamePasswordCredentials("myUser", "myPass"))
  provider
}

val connManager = {
  val mngr  = new PoolingHttpClientConnectionManager()
  mngr.setDefaultMaxPerRoute(Integer.MAX_VALUE)
  mngr.setMaxTotal(Integer.MAX_VALUE)
  mngr
}

val client = HttpClients.custom()
  .setConnectionManager(connManager)
  .disableRedirectHandling()
  .setDefaultCredentialsProvider(credProvider)
  .setProxy(new HttpHost(162.243.116.56, 71223 ))
  .build()

     val requestConfig = RequestConfig.custom()
       .setConnectTimeout(30000)
       .setConnectionRequestTimeout(30000)
       .build()


     val request = new HttpGet(url)
     request.setConfig(requestConfig)
     val response = client.execute(request)

How I can solve this problem (cause client to always send Proxy-Authorization )?

Answer 1

I'm not sure if it is the same problem, but with version 4.5.2 there was a bug introduced with the SPN (HTTP/something@somerealm) and https : HTTPCLIENT-1712 (the comments are especially interesting since they show a history of what happened).

A switch to version 4.5.1 should solve it (if this is the same problem of course)