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 <ol...@apache.org> 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 <ol...@apache.org>
> > 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 <ol...@apache.org
> > >
> > > > 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: 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
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
