On Sun, 2015-07-12 at 12:43 -0700, Derek Lewis wrote: > 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? >
Status code 401 alone does not constitute a valid auth challenge. Oleg > 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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
