The most part of my website is delivered with PHP and Apache,
which works just fine.
However I want to use Websocket for a page (or multiple pages).
For the Websocket communication I want to use golang.
To not let the clients run into any firewall problems Websocket should use the normal webport.
(443 that is in this case - for the SSL version of Websocket).
Because Apache is already listening on that port, I need it to forward Websocket requests (or requests to a specific URL) to my golang program.
(A single golang program must listen to all incoming websocket connections, to allow for easy communication between them.)
Is there a way to achieve that?
one of the web servers must proxy for the other. So you need to either configure Apache to proxy requests to your Golang program, or incorporate a reverse proxy into your golang program to deal with the Apache content.
It's probably easier to configure Apache as a proxy than include the reverse proxy into your Golang code, but there is a standard lib for it: http://golang.org/pkg/net/http/httputil/
Related
What makes nginx/apache a web server, HAProxy not?
What functionalities HAProxy lacks to be a web server?
HAProxy can listen on port 80 and can speak HTTP but that's not what people mean when they say "web server."
HAProxy is not a web server, because "web server" implies an HTTP endpoint that can serve static content from files and/or dynamic content generated from code. That's not what HAProxy is for.
Technically, there are certain capabilities in HAProxy that can be misused to emulate some capabilities of a web server -- you can serve very small static files from memory buffers and you can generate small dynamic responses using the optional embedded Lua interpreter -- but it is not intended or designed to be used as a web server. It's a proxy server -- emulating a web server toward the client, and emulating a client toward the real back-end web server(s) behind it -- because bidirectional emulation is commonly what proxies do.
With Nginx and Apache, you can specify a root directory from which files are served, and you can specify paths that are to be serviced by code running in languages like Perl, PHP, Python, etc. Not with HAProxy, because, again, that isn't what it's designed to do.
Both Nginx and Apache can also be used as proxy servers, as HAProxy can, but HAproxy is specifically designed and optimized for that primary purpose -- proxying and load balancing against multiple back-end, selecting the back-end using various rules and algorithms... in essence, HAProxy is an "intermediate router" for HTTP requests, delivering them rather than responding to them. It can also proxy and load balance non-HTTP protocols that rely on TCP.
I'm currently using an AJP proxy through apache to tomcat 8. I don't want to reason why I'm using AJP, but the basics are that Apache site outside the firewall while tomcat is inside the firewall with multiple apps being virtual hosted through the one apache instance.
A component to the app has been added with the need for websockets. I know that our current AJP implementation will not support websockets, however I'm looking for an alternative that someone else has confirmed working, i.e. different apache module, I'm using mod_proxy_ajp.
If there is no known module to allow this to work does anyone know of any works in progress for an enhancement to any of the existing modules or a new module?
FWIW I'm using spring4 websocket support with a STOMP endpoint and SockJS.
At the time of your question there is no solution for WebSocket support via AJP.
Apache does have mod_proxy_wstunnel but this support proxying of WebSocket using the HTTP protocol itself to the backend server. AJP work differently.
.
See this tomcat mailing list item for some useful background:
https://mail-archives.apache.org/mod_mbox/tomcat-users/201408.mbox/%3C53FF3A3A.3040507#christopherschultz.net%3E
I have a Play application that I've deployed by running stage within SBT, and then running it from the command line using target/start. I've placed Nginx in front of it and, based on a sub-domain, I have two server blocks--one for port 80, and the other for port 443. The port 80 block just redirects to the https scheme on port 443. This all works great.
To recap:
http://play.mydomain.com/ redirects to
https://play.mydomain.com/ which is a proxy for http://localhost:9000
However, if I just go to http://mydomain.com:9000/, I get access to my Play application directly. There's no SSL, and there's no way I can figure out to keep anyone from accessing it.
What should I do? Should I use Nginx to redirect any access on port 9000 to the URL for the SSL version? Should I firewall port 9000 and only allow local requests on that port? (If so, how would I do that?) Is there some other way of dealing with this that I'm not thinking of?
And how long until the Servlet 3.1 spec is released and I can just deploy the whole thing as a WAR? :-)
You could make your Play application listen only on the local interface (127.0.0.1, for example). That way, nginx can still proxy requests to it but nobody from the outside can access your application directly. No additional firewall setup is necessary.
Looks like you can pass an additional argument to start:
$ start -Dhttp.port=9000 -Dhttp.address=127.0.0.1
I created a WebSockets app to provide communication between connected clients, but I'm concerned about corporate firewalls and ISP rules that might block the port 8080 it's using. But the usual HTTP port 80 (that really no one would block) is already used by Apache on that server to provide the functionality for the rest of the app (which is a clasic web app running on PHP).
What are my options there? Are my concerns misplaced?
One option is to set up an Apache reverse proxy to make your app available via port 80. See (for example) Running a Reverse Proxy in Apache.
We've got an establish Apache/PHP site, with a Flash front-end. We're going to start to need to implement some sort of socket communication, or 'long-polling', to push updates to the flash app. Since this obviously isn't going to be a good situation for Apache, or PHP, I'd like to use Tornado for this aspect of the functionality, but I also don't want to run Tornado on another port, since the Flash app will be running on the client machine, we don't want to have to deal with restrictive firewalls blocking the socket connections.
Ideally I'd like to run a proxy which can forward most requests to Apache, and other requests to Tornado. I saw some suggestions for using Apache as the first-contact proxy, forward requests to Tornado when necessary, but I've also seen this discounts a lot of the async capabilities of Tornado.
I thought, why no use Tornado as the first-contact for port 80 and have it proxy back to Apache? I couldn't find anything on this at all and am wondering if this is even possible?
Another option would be to use something like lighttpd as the proxy and have it decide whether to pass things along to Apache or to Tornado, but does this kind of setup make sense? Or what about Nginx?
Any suggestions, advice or corrections on my understanding of things would be greatly appreciated!
This is called a reverse proxy and it's very easy to configure nginx to perform this. (lighttpd should also be able to do this job well, but I have no experience using it).
The tornado documentation has an example nginx configuration
One thing to note when using a reverse proxy is that the connection to your upstream server will now be originating from the proxy, not the client. The de facto standard is to put information about the original request in certain http headers. In the example from the tornado docs, the X-Real-IP header is set to the IP of the original client and X-Scheme is set to the scheme of the original request (http/https for example).
This may require some modifications to your upstream server. With tornado this is done by constructing the HTTPServer with the xheaders argument set to True. This will instruct the server to try and pull the IP address and scheme from the X-headers. Note that if you use this with a server that isn't behind a reverse proxy that sets the appropriate headers than you are open to IP Address spoofing.