Ok, that seems reasonable. However, I'm still confused about the behaviour. It seems like if a 401 or 403 (can't remember which one, but neither is working for me) is returned, HttpClient should try again, with the credentials that were in the URL. This doesn't seem to be happening. Would that seem to be the correct behaviour? Is there more to it that I'm missing?
I think I will still need to find a way to send the credentials pre-emptively, for performance reasons. I know HttpClient has a way to configure it to do that if you know the credentials and host. When they're embedded in the URL, there seems to be no way to do it without parsing them out of the URL to set in a CredentialsProvider. Is that correct? Sent from my iPhone > On Jul 11, 2015, at 10:06 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > >> On Fri, 2015-07-10 at 16:10 -0700, Derek Lewis wrote: >> Hi folks, >> >> >> I've been upgrading our software to a more recent (4.4.1) version of >> httpclient, and I've run in to a bit of a stumper. It seems like >> embedding the username/password in the URL isn't working with the >> client that's built by HttpClientBuilder. I've also tested this on >> 4.5, and seen the same outcome. >> >> >> On both the version we used before, and the new version, this >> deprecated code works: >> >> HttpClient httpClient = new DefaultHttpClient(); >> HttpGet get = new HttpGet(URL); >> HttpResponse response = httpClient.execute(get); >> >> >> With a URL to like "http://user:password@localhost:8123/any-file"; that >> requires basic-auth, this returns a 200. From the debug logs, I can >> see that an "Authorization" header is set on the first request, so >> it's sending it preemptively. >> >> >> However, with this new code: >> >> CloseableHttpClient httpClient = HttpClientBuilder.create().build(); >> HttpGet get = new HttpGet(URL); >> HttpResponse response = httpClient.execute(get); >> >> >> It doesn't set the "Authorization" header preemptively, and after >> receiving a 401 or 403 response, it also doesn't try again with the >> username and password that's in the URL. >> >> >> I've tried setting up an AuthCache: >> >> HttpHost targetHost = new HttpHost("localhost", -1, "http"); >> AuthCache authCache = new BasicAuthCache(); >> authCache.put(targetHost, new BasicScheme()); >> HttpClientContext context = HttpClientContext.create(); >> context.setAuthCache(authCache); >> >> >> But I don't have a username/password that I can store in a >> CredentialsProvider, without parsing the URL, since this URL is >> something that's passed to us as a callback, effectively. Parsing the >> URL doesn't seem like the right approach, since this used to work in >> httpclient. >> >> >> I'm unsure at this point if this is a bug, or just something I'm not >> configuring correctly. I've spent a couple hours googling and reading >> docs, but I haven't found anything that mentions inline credentials. >> >> >> I've put together a small demo/PoC of the problem I'm having in the >> form of a JUnit test. It starts an embedded http server, and hits it >> with httpclient in the three ways I've described, expecting to receive >> a 200 status. Only the deprecated code passes. It's only an 11K zip >> for the demo, so I've attached it. It uses maven, and all the >> dependencies are available from Maven Central, so running "mvn verify" >> should be sufficient. >> >> >> Thanks, >> >> Derek > > Derek > > Newer versions of HttpClient do not send user creds from the request URI > preemptively, only if challenged. See HTTPCLIENT-1344 > > https://issues.apache.org/jira/browse/HTTPCLIENT-1344 > > Oleg > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
