I haven't found any solution about this. It seems Jetty doesn't support this feature yet. I might be wrong so please, enlighten me.
I've got a very simple Java client which connects to a Java server at localhost:8080. I would like to add a transparent proxy between them in order to simulate what we could find in a company's private network.
Update: May, 2017
Starting in Jetty 9.4.0 and onwards, the native Jetty WebSocketClient supports Proxies via the Jetty HttpClient.
This works by declaring an HttpClient, along with its proxy configurations, and then handing that off to the WebSocketClient constructor to use.
This only works with the following:
HTTP/1.1 upgrade to WebSocket
Native Jetty WebSocket APIs
This does not work with the following:
HTTP/2 (there is no spec for WebSocket over HTTP/2 as of yet)
JSR356 javax.websocket (there are ideas for API breaking changes to the JSR356 ClientContainer to allow passing in a Jetty HttpClient via a constructor, let us know if this is viable option for you by filing a new issue on github saying so)
Original Answer
With Jetty 9, there's no Proxy support for either the Jetty Native WebSocket client, or the JSR-356 (javax.websocket) client implementation.
This support is scheduled for Jetty 10 (which is tracking Servlet 4), and will result in a complete reworking of the entire client library suite in Jetty to have equal support for :
HTTP/1.1
HTTP/2 (native/direct)
HTTP/1.1 upgrade to HTTP/2 (h2c)
HTTP/1.1 upgrade to WebSocket
HTTP/2 websocket channel (currently in draft specs)
Proxy support
Cookie support
etc ...
The existing WebSocket client implementations on Jetty are standalone, due to the JSR-356 support requirements.
The existing WebSocket client does not leverage the existing Jetty HttpClient in Jetty 9.x. If it did then proxy support could, maybe, under a very limited set of scenarios, work.
This is a low priority feature request, as there are few existing proxies out there that support WebSocket so far (actually, they have generally bad support for HTTP/1.1 upgrade). Even Jetty's own Server side Proxy does not currently support HTTP/1.1 upgraded connections.
According to Figure 2 in How HTML5 Web Sockets Interact With Proxy Servers, if you are trying to use a transparent proxy, you don't have to require a proxy support on the client side. On the other hand, an explicit proxy requires client libraries to support proxy.
Jetty WebSocket client won't have any problem if your proxy is transparent.
Related
Following Jetty documentation of enabling HTTP/2,
I reached till the following step,
2015-06-17 14:16:12.549:INFO:oejs.ServerConnector:main: Started
ServerConnector#6f32cd1e{HTTP/1.1,[http/1.1, h2c]}{0.0.0.0:8080}
From the docs,
No major browser currently supports plain text HTTP/2, so the 8080
port will only be able to use HTTP/2 with specific clients (eg curl)
that use the upgrade mechanism or assume HTTP/2.
The documentation mentions "specific clients", but what client I can use for overcoming this issue? I tried okHttp and apache-httpclient, okHttp doesn't support the upgrade mechanism (AFAIK, Would be great if it is otherwise), and apache-httpClient doesn't support h2.
I basically need to make GET/POST request from my program to this endpoint(Obviously, using HTTP/2).
To put in a simple words, Please suggest any Java client which support non-encrypted http/2 (h2c)
Thanks!
Apache HttpCore and HttpClient 5.0 support h2 as well as h2c but presently do not support the http/1.1 to h2c upgrade mechanism. I am not sure they ever will given it is unclear how useful this upgrade mechanism is in the first place.
For code examples please refer to
http://hc.apache.org/httpcomponents-client-5.0.x/examples-async.html
For HttpClient 4.5.x to HttpClient 5.0 upgrade guide please refer to:
https://ok2c.github.io/httpclient-migration-guide/
The Jetty Project has a HTTP client library that can be used as HTTP client and supports HTTP/2, both clear text and encrypted.
You want to look at this documentation.
See also how the Jetty Project uses that same client for tests.
I have a simple web app, which is using websockets.
simple webapp:
Frontend - using sockjs, stomp
Backend - Spring 4.2.x
Frontend & Backend are packaged in the same WAR, this WAR is deployed on IBM WebSphere Application Server v9.x
When I check the Developer Tools/Web Console in chrome(61.x)/firefox(56.0, 32 bit), I see that websocket transport is not being used, it's always xhr streaming. To use the websocket transport, I have passed the transports option in sockjs, like below, but after this change the websockets stopped working.
var sockjs = new SockJS(my url, null, {transports: ["websocket"]});
Do we need to change any configuration on IBM WebSphere Application Server v9.x to enable websocket transport ?
Update: on tomcat/liberty servers, sample app always uses websocket transport. Only on WAS, it is using xhr streaming. Issue in WAS?
Websocket protocol handling is on by default for Websphere v9.x
Tomcat 8 provides experimental support for SPDY protocol, according to these sources: Tomcat's Wiki, API docs, version 8.0.0 changelog.
I understand it's still work in progress but I'd like to try it out. Unfortunately there's very little documentation on the subject.
So has anyone used SPDY with Tomcat? Can you explain how to enable it or share needed configuration?
I was very successful in configuring NGINX with SPDY, and it's super fast. You could always use NGINX and proxy requests to Tomcat. Also, Jetty seems to have some great support for SPDY and SPDY Push features if you need native Servlet containers. As of today, nginx does not support SPDY push "Current implementation of SPDY protocol does not support “server push”.".
http://www.chromium.org/spdy
http://wiki.eclipse.org/Jetty/Feature/SPDY
Does anyone know if its possible to re-configure CometD to use the WebSphere Application Server instead of using Jetty? If so, is there much effort involved in porting it over if I've already got CometD running with Jetty?
CometD runs in any Servlet 2.5 or later Servlet Container, see here.
You did not specify the WebSphere version, but I assume it's a recent enough one.
The only CometD feature that will not work in WebSphere is the WebSocket transport, which is Jetty specific due to lack of standard WebSocket API (now filled by JSR 356 and supported soon in CometD 3).
Your CometD application should deploy and run with no changes in WebSphere, unless you tied yourself explicitly to Jetty APIs.
Can somebody please let me know how i can add long polling and other fallback support for websocket using Jetty 9?
I generally recommend using something like CometD (http://www.cometd.org) which will be releasing version 3 fairly soon which will support Jetty 9. Another option would be to look at the Atmosphere project.
Using a messaging framework like these let you have the framework handle finding the best protocol to use, be it SPDY, Websocket, HTTP/1.1 or even polling HTTP/1.0....and they isolate you from future protocols like HTTP/2 which is coming (slowly) which is based on spdy. Using CometD once that protocol lands and becomes available get it for free, no changes needed in your app.