On Fri, 2013-03-08 at 09:07 -0500, Karl Wright wrote: > Ok, what is happening can be seen here: > > >>>>>> > (Thread-20661) - << "HTTP/1.1 401 Unauthorized[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "Date: Fri, 08 Mar > 2013 13:32:51 GMT[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "Server: > Apache/2.2.22 (Unix)[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "WWW-Authenticate: > Basic realm="resin"[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "Content-Length: > 159[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "Content-Type: > text/html; charset=utf-8[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "X-UA-Compatible: > IE=EmulateIE7[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "Connection: close[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << "[\r][\n]" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Receiving response: > HTTP/1.1 401 Unauthorized > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << HTTP/1.1 401 Unauthorized > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << Date: Fri, 08 Mar > 2013 13:32:51 GMT > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << Server: Apache/2.2.22 (Unix) > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << WWW-Authenticate: > Basic realm="resin" > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << Content-Length: 159 > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << Content-Type: > text/html; charset=utf-8 > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << X-UA-Compatible: > IE=EmulateIE7 > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - << Connection: close > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Authentication required > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - solr-prod01.uio.no:443 > requested authentication > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Authentication schemes > in the order of preference: [negotiate, Kerberos, NTLM, Digest, Basic] > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Challenge for negotiate > authentication scheme not available > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Challenge for Kerberos > authentication scheme not available > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Challenge for NTLM > authentication scheme not available > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Challenge for Digest > authentication scheme not available > DEBUG 2013-03-08 14:32:51,446 (Thread-20661) - Selected authentication > options: [BASIC] > DEBUG 2013-03-08 14:32:51,447 (Thread-20661) - Connection > 0.0.0.0:35590<->129.240.120.16:443 closed > DEBUG 2013-03-08 14:32:51,447 (Thread-20661) - Connecting to > solr-prod01.uio.no:443 > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - CookieSpec selected: best-match > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Auth cache not set in the > context > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Target auth state: CHALLENGED > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Generating response to > an authentication challenge using basic scheme > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Proxy auth state: UNCHALLENGED > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Cannot retry > non-repeatable request > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Connection > 0.0.0.0:35591<->129.240.120.16:443 shut down > DEBUG 2013-03-08 14:32:51,448 (Thread-20661) - Connection > 0.0.0.0:35591<->129.240.120.16:443 closed > <<<<<< > > The problem is that HttpClient is discovering that it needs to use > Basic Auth after the fact, as a result of the response from the > server. >
This is what the 'expect-continue' handshake is for. It enables the client to verify server expectations prior to sending the request body. > For basic auth, at least, this is an inefficient interaction, because > the user often knows in advance that Basic Auth will be required at > the outset. While it's not an option for more involved authentication > methods such as NTLM, it seems likely to be an important case for > Basic Auth. Is there any way to signal HttpClient that I want to > provide pre-emptive authentication headers in that case? > Generally preemptive auth can pose security issues if used carelessly. One, however, one can pre-populate local auth cache to make HttpClient authenticate without being explicitly challenged. http://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientPreemptiveBasicAuthentication.java > If not, the next step is figuring out how to hand HttpClient a stream > that it is happy to replay. The particular stream in question *ought* > to be resettable, since it comes from a disk-based file in this case, > and yet it isn't showing up that way to HttpClient. I can do more > research, but how is this typically done? Should I create my own > HttpEntity extension that has the right characteristics? HttpClient comes with a number of HttpEntity implementations including those backed by a byte array, a string or a file. Probably all you have to do is to use the right implementation. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
