On Nov 20, 2008, at 3:42 PM, Jorge L. Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paul Sandoz wrote:
>> 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.
>>
>
> The default for PROPERTY_PREEMPTIVE_AUTHENTICATION is already false.
>
> As for, PROPERTY_INTERACTIVE, I distinctly remember that prompting
> for credentials was the default behavior when using URLConnection and
> I wanted to match the behavior in case people were relying on it. Now
> that I look at the documentation, I guess I must have dreamt that
> behavior because I can't find a reference to it. Keep in mind that,
> if you set interactive to true, but also set the credentials in the
> Config you will *not* be prompt.
OK.
> None the less, I really don't have
> a problem with setting the default to false.
>
>> - Rename: PROPERTY_INTERACTIVE ->
>> PROPERTY_AUTHENTICATION_INTERACTIVE
>> PROPERTY_PREEMPTIVE_AUTHENTICATION ->
>> PROPERTY_AUTHENTICATION_PREEMPTIVE
>>
> Good idea, no problem.
>
>> - 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.
>>
> Another good idea. Here, again, I was trying to match the behavior
> of the java.net package.
>> - Have a method HttpClientConfig.getHttpState() thus the
>> credential-based methods could be re-factored to a helper class or
>> just reside on the DefaultHttpClientConfig.
>>
> Okay, here I disagree. I really don't like the developer having to
> know anything about HttpClient in the typical case. Not having to
> visit the Javadocs for the HttpClient api just makes the backend
> easier to use. I think setting credentials will occur quite frequently
> so I'm a little reluctant to have the user have to manage an HttpState
> or have to know anything about it to work with the ClientHandler.
>
> Of course, I'm open to the idea, but I guess I don't understand why
> you're making this suggestion(?) Is it because you feel it will
> address a security issue? Please explain.
I am guessing that there may be other ways to configure the HttpState
beyond the common cases.
A way to get or set the HttpState might be useful. A filter could
create/use a different HttpState and set it on the properties e.g. i
could have credentials set up for a particular WebResource using a
filter to add the HttpState to the properties.
I was not proposing to remove the methods or for the ClientHandler to
be utilized. I think they are useful, and maybe so in a different
context.
>
>> - I think we need to implement a RequestEntity specific to writing
>> so that we do not buffer the request.
>>
> We are in accord on this.
>
> I'm spread a bit thin these days and won't be able to address these
> issues until sometime next week.
>
I will try and do something tomorrow,
Paul.
> - -jOrGe W.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkkld0wACgkQ72r0i/n44hM/swCfex0il6dNn7IB5ywGwNS92wBR
> 5bIAnjER5QGxyl/BE6qs+PE+IfPATA79
> =qjDP
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>