On Thu, 2014-07-31 at 12:32 -0700, Gregory Chanan wrote:
> 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?
Hi Greg.
HttpClient has traditionally suffered from feature creep. We have
several areas of codes that we are not able to maintain adequately due
to the lack of expertise or resources. Most of them (if not all) started
out as a big code drop by an external contributor. I am a little
concerned about accepting a substantial body of code that may be of
interest to a small group users only.
Having said all that let's see what can be done in HttpClient to help
reduce code duplication.
Oleg
>
> Thanks,
> Greg
>
>
> On Wed, Jul 30, 2014 at 1:58 AM, Oleg Kalnichevski <ol...@apache.org> 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 <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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
