Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Jetty client


On Fri, Sep 6, 2013 at 7:44 PM, Mikhail Mazursky <ash2kk@xxxxxxxxx> wrote:
> 2013/9/6 Simone Bordet <sbordet@xxxxxxxxxxx>
>> Hi,
>> On Thu, Sep 5, 2013 at 6:47 PM, Mikhail Mazursky <ash2kk@xxxxxxxxx> wrote:
>> > Hello.
>> >
>> > Few questions about Jetty Client:
>> >
>> > 1. Do it support SNI [1]? For example Apache Http Client do not [2] and
>> > we
>> > want to switch maybe to Jetty Client or some other.
>> Not sure about your question here.
>> The client side of SNI is taken care of in modern JDKs, which send the
>> SNI TLS extension by default to servers.
>> The current problem in Java is that it is not readable by servers.
> AFAIK only SSL connections created using URL class use SNI. SSL sockets that
> are created manually have to be explicitly set to use SNI by using setHost
> method (as demonstrated by the link in the Ryan's email). But I may be wrong
> here.

Being asynchronous, HttpClient does not use SSLSocket.
It uses SSLEngine, which does set the SNI (under certain conditions,
but they are usually met).

>> > 2. Are there any plans to support JSR-339 [3]? I think it can be usefull
>> > to
>> > abstract implementation and be able to switch them. I found two
>> > implementations of this JSR - Jersey [4] (reference implementation) and
>> > Apache CXF [5]. I'm not sure what the CXF project is but looks like it
>> > supports this JSR.
>> JSR 339 is about a REST API on the server side.
>> I am not sure what you mean here about the client side.
> JSR 339 also defines client api, take a look at chapter 5 of the spec.

Ah, I missed that.
We don't plan to support JSR 339, certainly not on HttpClient itself
(API conflict).
It would be fairly easy to implement JSR 339 on top of HttpClient though.

Simone Bordet
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

Back to the top