Doesn't have to be Apache, but that's just the only HTTP server I know of (Actually could you guys recommend alternatives that I could look into as well?)
Anyways, so I have been messing around with Amazon Web Services and I created an EC2 server instance with an Amazon Linux Image. On that, (Following guides and examples) I installed Apache and now when I make a GET request to my public IP, it returns to me the HTML files I created on my server.
My question is, what if I never installed Apache, and then made an HTTP request to my public IP? For no reason really, the question just came up in my head and I'm curious. I'd rather not figure out how to uninstall Apache or create a new instance to figure it out, so I was wondering if somebody could weigh in as well as tell me a little more about what it is exactly apache does on a server. My understanding is that it is a layer you can install on your server OS that will create a socket listener to port 80 (HTTP), and when a request is made on that port, Apache will return web pages? Also I think I read somewhere you could configure Apache to forward a port to something like a python server script?
Thanks in advance for your time!
could you guys recommend alternatives that I could look into as well?)
nginx is a popular alternative to apache. It's much more efficient.
what if I never installed Apache, and then made an HTTP request to my public IP?
Your browser would get a "connection reset" because there is nothing on port 80. Your browser would display a message (Chrome says "This webpage is not available"). You would NOT get a "404" because that requires an HTTP server to send HTTP codes.
If your server was firewalled instead, you'd bet a busy wait for a while, then a message about the server not responding.
Also I think I read somewhere you could configure Apache to forward a port to something like a python server script?
Yes, that is called "reverse proxy" mode. It's essential to any application website if you want to scale. The web server(s) can distribute traffic to one or more backends running the application. The web server is useful for filtering bad requests (since your backend in Ruby/Python will be 1000's of times slower than the reverse proxy.)
Well, if you want to test what will happen if Apache isn't installed, you can always just stop the Apache service by typing:
sudo service apache2 stop
or
sudo service httpd stop
depending on your version. Then if you visit your site's webpage you'll get a 404 error or something similar.
There are ways to use python scripts to run simple servers, but in general it's easier to just let Apache handle that and use a framework like Ruby on Rails or Django to control the display and creation of content for your server.
Related
I've been researching how to connect Tomcat and apache http server because I will have my web application written in angular deployed in apache http server 2.2 (currently succesfully tested on my own computer, local), and my REST service written in java deployed in Tomcat v6,
and what I want now is that when some component is clicked, to make a http request (like this http://localhost:8080/rest/getCars/20130505) that connects with the servlet and use the json provided to use the information provided in another component.
So I have created my own url/json to test the web application on itself, but as I said, it is possible to make the same thing but with a real http URI like it can be seen here: https://angular.io/docs/ts/latest/guide/server-communication.html#!#cors
They use:
let wikiUrl = 'http://en.wikipedia.org/w/api.php';
And I use, as of right now:
private datesUrl = 'src/example.json'; // URL to web API
#Injectable()
getDates(): Observable<Date[]> {
return this.http.get(this.datesUrl)
.map(this.extractData)
.catch(this.handleError);
}
So I believe my next step would be to change that datesUrl and write the http written above: http://localhost:8080/rest/getCars/20130505, so that it connects to Tomcat.
But my problem is that I don't know if this is going to work without any connection done between apache http server and tomcat. I've seen there are connectors, like mod_jk and mod_proxy http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass
and so on. I would like to know if, in my case, if I need to use this modules for apache http server or it's not necessary, since I have never seen any of this and install the modules is proving to be a challenge. The end game objective I have is to go from local to a real server, but as far as I know there is no need for anyone from the outside to use the webpage, it's only for the business itself, so with access to the server/machine I could still access localhost, same as I do when I test it locally.
You don't need any special connection between the PHP server and the Tomcat server: it's a plain-old HTTP request. Tomcat doesn't care if your PHP script made that request, or if it came from the open internet.
In the case of the PHP script making the request, it's making its standard HTTP call, and doesn't care that you are running a Tomcat server locally or whatever. Just go ahead and do it. If Tomcat is already responding to HTTP requests on that URL, then calling it from PHP requires no further configuration.
I created an api using SLIM framework, but the services are not accessible to public as they are limited to localhost. how to host the services on a realtime server, so that, they can be accessible from anywhere?
please some one help me
This question requires more detail in order to answer properly.
If you are hosting your API on a windows server, then it is likely you have configured some kind of "WAMP" stack, correct? Or maybe serving PHP through IIS? This are important questions because we need to know what port you have bound your web application server to, which leads us to the next question...
Where are you hosting the server which is running the application which bound to what port?
Ultimately, a public, external IP will need to be either:
a. NAT'ed to the internal IP of your web server instanced
b. Port-forwarded to the internal IP of the server running your web application
Still, we are making a lot of assumptions here because getting a web application "accessible from anywhere" will require different work depending on your environment.
Here is the most basic example:
You are at home, running this API on your Windows workstation and will like to be able to hit it from a remote location.
Ensure Windows firewall allows inbound traffic to the port on which your application is running (probably port 80/HTTP, maybe 443/HTTPS).
Log into your ISP's router and configure port-forwarding to ensure inbound traffic on, say, port 80, is routed to the internal IP of the workstation running the API.
That's all there is to it.
Keep in mind that this also assumes that your ISP even allows you to expose your own web server to the internet on port 80 (or 443). Also, since we know nothing about your environment, this is all pure conjecture. Please provide more information you would like a real answer.
The most traditional way to host Slim Framework, would be through Apache. Install Apache and be sure you have the proper network settings to allow inbound connections, but more information about your setup could be needed for proper guidance.
http://httpd.apache.org/docs/2.4/platform/windows.html
When Apache is installed and working, you need to set Rewrite rules on the URL, information on that can be found on http://docs.slimframework.com/routing/rewrite/.
Your question on the verge of off topic, it probaly is, but read up on what questions can be asked and not, here on Stackoverflow, hope i could help.
I have a problem running ServiceStack as daemon on Linux.
I just started to work into creating a REST API with C# on Mono. I studied your Wiki about it and yesterday I tried to run ServiceStack as daemon on Linux (Ubuntu 13) exactly as described on the wiki page:
https://github.com/ServiceStack/ServiceStack/wiki/Run-ServiceStack-as-a-daemon-on-Linux
But I encountered a problem, tried every possible solution I found in the web, but nothing helped.. The problem:
If I access http://127.0.0.1:8080 on the Ubuntu System everything is fine and I am beeing redirected to http://127.0.0.1:8080/metadata and get the Service Metadata.
If I access http://127.0.0.1:80 I get the static content. Also fine.
BUT if I access http://127.0.0.1/api I'm being redirected to http://127.0.0.1/metadata and get a 404. Which is absolutely understandable because there is no such thing on Port 80.
You know I'm not that good in apache, but after reading the configuration mentioned in the wiki I thought this should work normally. Am I wrong? Or do you have any idea how I can solve this?
Another problem is that if i access the service on my ubuntu system from another system, e.g. Windows through http://ubuntu-dev:8080, I get Bad Request (invalid host).
I also get the 404 there if I accesshttp://ubuntu-dev/api.
I think the Bad Request Thing must have something to do with servicestack because apache only listens on port 80 (as it should I think). Do you have any suggestions about this?
It would be really nice if someone could help me because I really don't know what to do with these problems.
Greetings, daily
It might be a problem that only occurs when it runs on a different port than 80.
Probably it's not redirecting properly when a port is set.
Try running it on nginx with fastcgi (fastcgi-mono-server4), there you can run it on port 80.
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.
I hope this doesn't come across as a terribly silly question, but I'm learning how to implement a socket.io server for my website to produce real-time applications, but my problem is that I can't figure out how to implement said applications in an Apache served environment. Currently, when I run node server.js to start my socket.io server, I have to access it by visiting http://localhost:XXXX where XXXX is whatever port I attach it to, naturally. I don't want my website to be forced to be viewed on an alternate port like this, but I obviously can't attach the server to port 80 since Apache is listening on that.
Obviously a natural solution would be to stop the Apache service and then node the server on port 80 that way to avoid a collision, but I don't want to sacrifice all of the functionality that Apache offers. Basically, I want to continue to serve my website via Apache on port 80, and integrate certain aspects of real-time applications via socket.io on port 3000, let's say.
Is there a way to do this that avoid the things I don't want? Those things being 1) having users access my site with :3000 in the URL, 2) disabling Apache, 3) using iframes.
Thanks in advance.
Generally, you should be able to hide Node.js with mod_proxy. A bit of searching turned up this: https://github.com/sindresorhus/guides/blob/master/run-node-server-alongside-apache.md (old link died, this is a new one)
However, Socket.io can be a bit finicky (https://github.com/LearnBoost/socket.io/issues/25), so you may have problems with it specifically.
As that ticket is a bit old, it's worth a shot. Just don't be surprised if you have problems. You're next bet after that is bind Node.js toport 80 and have it act as a reverse proxy for Apache with https://github.com/nodejitsu/node-http-proxy (still under a fair bit of development).
The optimal solution would be run it on it's own server and just have you're socket traffic go to socket.example.com or something like that.
Socket.io has multiple transport mechanisms. Some of them don't work if you run Apache as reverse proxy, but some do. Transports that don't work are websocket and flash, but xhr-polling and jsonp-polling should work.
Here's an example on setting the transports configuration option for socket.io:
var io = require("socket.io").listen(server);
io.set("transports", ["xhr-polling", "jsonp-polling"]);
On my Apache I'm using the normal name based virtual hosts and reverse proxy setup and with these transports the socket.io seems to be working.