On 10/01/13 21:57, Bill Burke wrote:
>
>
> On 1/10/2013 5:11 AM, Sergey Beryozkin wrote:
>> On 09/01/13 21:05, Bill Burke wrote:
>>>
>>>
>>> On 1/9/2013 11:26 AM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Jan 8, 2013, at 11:12 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>
>>>>>
>>>>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/AbstractClientBuilder.java
>>>>>
>>>>>
>>>>>
>>>>
>>>> I'm certainly not an SSL expert, but overall it looks good to me.
>>>> Seems to address keystores, SSL context, etc. Some questions:
>>>>
>>>> (1) Are there defaults for all these builder methods if not called? Or
>>>> will build() throw an exception if the building process is somehow
>>>> incomplete?
>>>>
>>>
>>> No failures if something not called.
>>>
>>> defaults are:
>>> * SSL connections will fail unless JDK's default truststore trusts the
>>> server you are connecting too. Disabling verification is a huge security
>>> hole.
>>> * Not defining a connection pool size, the pool size defaults to zero.
>>>
>>>> (2) What's the rationale/advantage of supporting per-hostname
>>>> connection pools here?
>>>>
>>>
>>> Just copying Apache Client. Could be total connections pooled, or
>>> whatever.
>>>
>>>> (3) Is there a relationship between this builder and Resteasy's
>>>> implementation of ClientFactory?
>>>>
>>>
>>> Its what we use at the moment. I'm already using it.
>>>
>>> I'm also thinking maybe we have a cookie flag that states whether
>>> cookies should be saved and transmitted or not.
>>>
>>>
>>> I think SSL, pooling, and cookies are all the major features of Apache
>>> Client that people use.
>>>
>> The API should not be centered around Apache Client, if this API can be
>> applied equally well to the default JDK URL connection/etc then it is
>> OK, otherwise not
>>
>
> The API is centered around features that people use. I've talked to a
> few users about me wanting to replace AHC. The main feaures are
> SSL/HTTPS, pooling, cookies, and caching. IMO, I just don't see how we
> can release JAX-RS 2.0 without at least SSL/HTTPS configuration options.
>
>
I'm not objecting to this. IMHO the API which can only be reasonably
implemented on top of Apache HTTP client (well known framework which I
respect too) is not a spec-level portable API.
+1 to having whatever security features supported that can be reasonably
implemented on top of various HTTP stacks, in Java land it is Apache
HTTP client and built-in HTTP stack, two most popular ones...
Cheers, Sergey