Trying again on a reply - google seems to have deleted my previous attempt.
> This is what the 'expect-continue' handshake is for. It enables the > client to verify server expectations prior to sending the request body. Is there a reason this isn't getting used? Is it gated by server behavior, or is there a setting in HttpClient that allows it to work? > 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. Problem is that ManifoldCF output connectors get an inputstream handed to them, not a file. But I was asking this question to see if anyone knew why a resettable input stream wouldn't work. Because, it doesn't seem to. Thanks, Karl On Fri, Mar 8, 2013 at 9:48 AM, Oleg Kalnichevski <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
