Thanks once again Oleg, I will investigate. FWIW, do you think something like this (or at least making it easier to implement without duplicating a bunch of code) would be a useful addition to httpclient? As it stands, what I implemented at the application level (sending GET before POST/PUT) only happens to work because I use the BasicHttpClientConnectionManager that reuses the connection. That is, it's not a general solution in the case the user is configuring their own httpclient and passing it on to the application code. I can't really guarantee PUTs or POSTs will work with SPNego without it.
Thanks, Greg On Wed, Jul 30, 2014 at 1:58 AM, Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2014-07-29 at 15:21 -0700, Gregory Chanan wrote: > > Hi Oleg, > > > > I tried using tunnelTarget with the 4.2.x APIs, but it doesn't seem to be > > called during normal execution, perhaps it is only called when a proxy is > > enabled. > > > > Using the 4.3.x APIs I was able to see routeComplete being called when I > > expect it. However, my attempts to generate a GET at this time to > trigger > > the SPNego negotiation were not successful. It seems that a new > connection > > is being created which does its own negotiation, rather than the > > negotiation being done on the original connection. Any ideas on how I > can > > solve this? > > > > My code is basically as follows: > > public void routeComplete( > > HttpClientConnection conn, > > HttpRoute route, > > HttpContext context) throws IOException { > > connman.routeComplete(conn, route, context); //my class is just a > > wrapper around a ClientConnectionManager, have the actual > > ClientConnectionManager do its work > > client.execute(route.getTargetHost(), new HttpGet(), context); // I > > create a new wrapper for each client, so client is just the HttpClient > > associated with this wrapper > > // error handling, etc > > } > > > > Thanks, > > Greg > > > > Greg > > I think you should only be using methods of HttpClientConnection (or > possibly a dedicated instance of HttpRequestExecutor) to send and > receive raw HTTP messages. You also likely have to duplicate some of the > authentication code in your custom connection manager to make SPNego > handshake work. > > Oleg > > > > > On Wed, Jul 23, 2014 at 4:56 AM, Oleg Kalnichevski <[email protected]> > wrote: > > > > > On Tue, 2014-07-22 at 17:13 -0700, Gregory Chanan wrote: > > > > Thanks, Oleg. > > > > > > > > Just to check, why would it not work for me to override > > > > ManagedClientConnection.tunnelTarget ( > > > > > > > > http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ManagedClientConnection.html#tunnelTarget(boolean > > > , > > > > org.apache.http.params.HttpParams) in 4.2.x? The documentation > seems to > > > > indicate that the route (including immediate proxies) has been > completed > > > at > > > > this point. > > > > > > > > > > I should probably work as well. I may have been wrong. > > > > > > Oleg > > > > > > > Thanks, > > > > Greg > > > > > > > > > > > > On Tue, May 20, 2014 at 8:13 AM, Oleg Kalnichevski <[email protected] > > > > > wrote: > > > > > > > > > On Mon, 2014-05-19 at 14:47 -0700, Gregory Chanan wrote: > > > > > > Hi Oleg, > > > > > > > > > > > > Thanks, that makes sense. Any equivalent for httpclient 4.2.5? > I > > > use > > > > > both > > > > > > 4.2.5 and 4.3.3. > > > > > > > > > > > > > > > > Unfortunately 4.2 APIs do not provide an equivalent method. > > > > > > > > > > Oleg > > > > > > > > > > > Thanks, > > > > > > Greg > > > > > > > > > > > > > > > > > > On Wed, May 14, 2014 at 4:10 AM, Oleg Kalnichevski < > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > > > On Tue, 2014-05-13 at 17:05 -0700, Gregory Chanan wrote: > > > > > > > > I'm using httpclient (4.3.3) in my application with > > > SPNEGO/Kerberos > > > > > Auth > > > > > > > > and everything works well when a GET is the first request to > a > > > remote > > > > > > > > host. This is consistent with > > > > > > > > > > > > > > > > > > > > > > > > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html#spnegowhich > > > > > > > > only discusses SPNEGO with GET. > > > > > > > > > > > > > > > > I run into problems in my application if POST is the first > > > request; > > > > > there > > > > > > > > are a couple of different given the SPNEGO negotiation. What > > > I've > > > > > done > > > > > > > is > > > > > > > > address this at the application level: if a POST is being > > > requested, > > > > > I > > > > > > > > first generate a GET in order to trigger the SPNEGO > negotiation, > > > then > > > > > > > send > > > > > > > > the POST. > > > > > > > > > > > > > > > > There are a couple of downsides to this approach, though: > > > > > > > > 1) It's inefficient because I send the GET each time a POST > > > request > > > > > is > > > > > > > > made, not once per connection. > > > > > > > > 2) I have to change the application code everywhere > httpclient > > > > > requests > > > > > > > are > > > > > > > > made > > > > > > > > > > > > > > > > Anyone have a suggestion for how to address this? I was > > > thinking of > > > > > > > > implementing by own HttpClientConnectionManager that > overrides > > > > > "connect" > > > > > > > > and sends the GET after the connection is established. That > way > > > I > > > > > > > address > > > > > > > > 1) because I only send the GET once per connection and 2) I > can > > > get > > > > > rid > > > > > > > of > > > > > > > > the changes in my application code and just use normal > > > HttpClients. > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > Gregory, > > > > > > > > > > > > > > It is a reasonable approach. However, you should overrride > > > > > > > #routeComplete method instead of #connect. This will enable > you to > > > > > > > interact with the connection immediately after its route has > been > > > fully > > > > > > > established. Otherwise, your connection manager would not work > > > > > correctly > > > > > > > with tunneled connections (for instance, https requests via a > > > proxy). > > > > > > > > > > > > > > Hope this helps > > > > > > > > > > > > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
