I try to use Tomcat implementation of WebSockets on local machine.
When I use only tomcat everything works fine, but when I start use bundle Apache + mod_jk + Tomcat browser show me 'The connection to ws://example.com/test/echoMessage was interrupted while the page was loading' after couple of seconds of work. WebSocket connection is closed after this.
Can anyone tell me how to fix it?
I have: Apache HTTPD 2.2.18, mod_jk 1.2.37, Tomcat 7.0.28
Here is server side code that I use: http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/ and client side: http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/websocket/
Browsers: Firefox 12, Chrome 19
I would research whether Apache mod_proxy is able to transparently forward traffic at the TCP level at all. Since that is likely needed for WebSocket to pass through. IOW: is mod_proxy able to transparently reverse proxy WebSocket traffic?
But why would you want to bring Apache in the line anyway? It doesn't add any value, only more parts which can break. That is for WebSocket of course ..
Related
Situation:
My client has a Java web application deployed on a JBoss server, it is accessed both via HTTPS and HTTP
The JBoss server is sitting behind a load-balancer that handles the SSL, in other words this load-balancer terminates SSL and sends requests to JBoss as plain HTTP
Problem I need to solve:
The web application deployed on JBoss needs to know what port the load-balancer is using for HTTPS, so that it can direct users to certain HTTPS urls correctly. This cannot be hard-coded because the application will be deployed on multiple clients, each of them have different configurations for the load-balancer.
My approach (which didn't work):
I am defining the port from a jspx page, via ${pageContext.request.serverPort}, but this always returns the port for HTTP because JBoss always gets the request via HTTP.
Thanks in advance. I've looked at this question but was not helpful.
There isn't really a way to determine the port if tomcat is sitting behind a load balancer. As suggested in the comments, exposing the port configuration to your clients would be the best for now.
I am trying to find a solution for a Server Independent WebSocket implementation, Tomcat inbuilt WebSocket API is good but it's not running in Weblogic and other servers .
I found a solution with Tyrus API , but all examples of Tyrus is done with grizzly web server , where it starts a separate server with a new port to accept ws:// request , but it has another option which is ServerContainer, where it will work with any Servlet Container web server and will use the existing Server port only, but unfortunately no example i found .. I am looking forward to any other options also ...
I have a java application running on a server IP 1.1.1.1 port 111
I have an Apache server running on IP 1.1.1.2 port 80
Apache should be configured as a proxy.
Clients will configure their computers to point to my Apache proxy at 1.1.1.2 port 80
The question is could i configure the Apache server to redirect the requests coming from the client to the java app for processing and if the java app sees that it should deny the request then it will inform Apache and Apache by its turn should informs the client.
Am i dreaming or this could be implemented?
Any suggestions would be very helpful
Yes, this is possible. Have a look at the mod_proxy plugin for Apache. There are a few security and implementation considerations to cover, such as:
Is the site to be accessed via a new virtual host defined in Apache, or an existing one?
HTTP vs HTTPs access? (From your post, it seems like the decision is to use HTTP port 80)
What URL(s) to match on for the proxy rule to trigger?
Is the access allowed from all IP ranges or only a particular subnet?
Is there a benefit in offloading some of the static resources to the Apache server to ease the load on the backend application server, or using a mod_deflate to gzip the resources before forwarding them to the clients?
mod_proxy documentation
I'm trying to setup a Solaris KSSL proxy (http://www.c0t0d0s0.org/archives/5575-Less-known-Solaris-Features-kssl.html) as a frontend to a Jetty web server.
I'm able to make KSSL work with Apache web server so that KSSL redirects all incoming SSL traffic from port 443 into an Apache web server listening on port 28080.
However the same configuration does not work when Jetty is listening on port 28080. I verified that the KSSL requests does not even reach Jetty or at least I cannot see them in the access log. Furthermore even if I set a simple Java class which just listens on a server socket, KSSL cannot redirect requests to it.
My question is what are the pre-requisites from a web server in order to be able to get requests from KSSL ?
Best regards,
Lior
There are 2 very common gotchas when working with kssl.
The first is that the apache listening IP has to be the same
as your ksslcfg command. So if you have Listen 123.123.123.123:28080 in
the httpd.conf file, then you must use a ksslcfg command with the same IP.
You cannot have it listening on ANY (*) and then list an IP in ksslcfg,
or listen on an IP and leave out the IP on ksslcfg. Whatever netstat shows
is listening on port 28080 must match the IP used in ksslcfg
(or don't use the IP it is listening on *)
The second is that you must do the operations in this order:
ksslcfg
restart apache
It doesn't not work if ksslcfg is run without restarting apache afterward.
I've seen many people on the web testing with something like
localhost in their ksslcfg command. It won't work unless you also
had localhost as the Listen IP in the apache configuration.
I have a web-service endpoint and a http connector on port X.
At some point this endpoint needs to switch to https, but on the same port!
(I know this is not the normal way of doing things, but this is what my clients expect from an old server they are using...)
Is there a way to do it in tomcat?
This is not possible with Tomcat.The HTTPS connector will accept SSL connection only.
We have such a proxy developed in house. It's not that hard to do. You just need to check the first incoming packet. Looking for the pattern of SSL handshake. We only look for CLIENT_HELLO. Once you figure out the protocol, you can forward the request accordingly.
This is really ugly. You shouldn't do it if all possible. We have to do it because the legacy clients do this and it's impossible to upgrade them all.
There is such a thing as HTTPS upgrade, whereby a plaintext HTTP connection is upgraded to HTTP by mutual agreement after it has been formed. Is that what you mean? If so, Tomcat doesn't seem to support it out of the box, and neither does Java out of the box either. You can probably write yourself a Tomcat Connector that will do it; on the client end you have a more interesting problem ;-)
But I would ask why? Ports aren't so expensive that you can't use two.
You don't need to run the HTTP & HTTPS on same port, Configure the Tomcat to redirect requests to HTTPS in server.xml file.
well I wonder why they are NOT usually on the same port! wouldn't that be easier?
the reason is probably that related Java APIS (javax.net.ssl) don't allow that; you must have different server sockets. are there any alternative SSL impls for Java? I'm not aware of any.