users@jersey.java.net

Re: [Jersey] Patch: HttpClient backend to Jersey Client

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 20 Nov 2008 14:28:42 +0100

Hi Jorge,

I have looked more closely at the patch, some comments and proposed
improvements:

- Alex pointed out to me that by default interactive prompting for
credentials occurs.
   I think the default value for PROPERTY_INTERACTIVE and
PROPERTY_PREEMPTIVE_AUTHENTICATION should be
   false, since by client API is likely to be used in non-interactive
environments.

- Rename:
    PROPERTY_INTERACTIVE -> PROPERTY_AUTHENTICATION_INTERACTIVE
    PROPERTY_PREEMPTIVE_AUTHENTICATION ->
PROPERTY_AUTHENTICATION_PREEMPTIVE

- Change the properties PROPERTY_PROXY_SET, PROPERTY_PROXY_HOST,
PROPERTY_PROXY_PORT to one
   property PROPERTY_PROXY that is a string or URI, which if the port
is absent then 8080 is used.

- Have a method HttpClientConfig.getHttpState() thus the credential-
based methods could be re-factored to a helper
   class or just reside on the DefaultHttpClientConfig.

- I think we need to implement a RequestEntity specific to writing so
that we do not buffer the request.

Thoughts?

Paul.

On Nov 18, 2008, at 2:27 AM, Jorge L Williams wrote:

>
> Okay I'm a little lazy so some of this e-mail is a cut and paste
> from one I posted to the user mailing list last week...
>
> I've added support for Basic, Digest, and NTLM authentication and
> preemptive authentication by adding an Apache HTTPClient backend to
> Jersey client. Cookie handling is also supported -- though off by
> default. This also fixes other errors associated with
> URLConnections like not being able to retrieve 401 error codes.
> Also, HTTPClient seems perform better than URLConnection -- though I
> haven't done any real benchmarking -- it does feel snappier! As as
> side note, I've also modified the WADL2Java implementation so that
> it uses Jersey client as a backend -- as a way of providing support
> for these features from a generated WADL client.
>
> I took the approach of simply creating a root ClientHandler and
> ClientConfig class (under impl). I didn't touch any of the Jersey
> Client API code.
>
> Basically the usage looks something like this:
>
>
> DefaultHttpClientConfig clientConfig = new DefaultHttpClientConfig();
>
> //
> // Set the credentials (realm, host, port, username, password)
> //
> clientConfig.setCredentials (null, "host.inl.gov", 443, username,
> password);
> clientConfig.getProperties().put
> (HttpClientConfig.PROPERTY_PREEMPTIVE_AUTHENTICATION, Boolean.TRUE);
>
> Client c = new Client (new HttpClientHandler(), clientConfig);
>
>
> I've been testing my implementation for a week or so and things
> seems stable.
>
> You might want to look at the documentation for the HttpClientConfig
> class for an idea of what features are supported. I've tried my
> best to shield developers from the details of Apache HTTPClient as
> much as possible. You only need to instantiate a class from the
> HttpClient package if you want to use a custom credential provider.
>
> Some other things to keep in mind:
>
> * There is a single HTTPClient per HttpClientHandler. It may be
> worth while to use it as a root for multiple Clients to save on
> resources. There should typically be a single HttpClientHandler per
> application.
> * Client operations are thread safe, the HTTP connection may be
> shared between different threads. If you retrieve a response entity
> input stream you must call close() on the stream when you're done
> with it in order to release the connection to other threads.
> * In this initial implementation, only standard methods (GET,
> POST, DELETE, OPTIONS, HEAD, and PUT) are supported.
> * Chunk encoding is a true/false operation in HTTPClient
> there's no way of specifying a chunk size. If you set
> PROPERTY_CHUNKED_ENCODING_SIZE to anything other than null it will
> be set to true.
> * In this initial implementation, chunk encoding probably
> doesn't matter since we write entities to a byte array before we
> transmit them
>
> Possible Security Flaw:
>
> Credentials get passed from an HttpClientConfig to an
> HttpClientHandler via ClientConfig properties. I'm not sure if this
> poses a security threat, but I'd figure I'd mention it. Is there a
> better way of doing this? I couldn't find a good connection
> between a ClientHandler and a ClientConfig...
>
> Anyway, let me know if you have any issues,
>
> jOrGe W.
>
> <
> httpclient
> .patch
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net