I have a public web server with the following software installed:
IIS7 on port 80
Subversion over apache on port 81
TeamCity over apache on port 82
Unfortunately, both Subversion and TeamCity comes with their own web server installations, and they work flawlessly, so I don't really want to try to move them all to run under IIS, if that is even possible.
However, I was looking at IIS and I noticed the HTTP redirect part, and I was wondering...
Would it be possible for me to create a HTTP handler, and install it on a sub-domain under IIS7, so that all requests to, say, http://svn.vkarlsen.no/anything/here is passed to my HTTP handler, which then subsequently creates a request to http://localhost:81/anything/here, retrieves the data, and passes it on to the original requestee?
In other words, I would like IIS to handle transparent forwards to port 81 and 82, without using the redirection features. For instance, Subversion doesn't like HTTP redirect and just says that the repository has been moved, and I need to relocate my working copy. That's not what I want.
If anyone thinks this can be done, does anyone have any links to topics I need to read up on? I think I can manage the actual request parts, even with authentication, but I have no idea how to create a HTTP handler.
Also bear in mind that I need to handle sub-paths and documents beneath the top-level domain, so http://svn.vkarlsen.no/whatever/here needs to be handled by a single handler, I cannot create copies of the handler for all sub-directories since paths are created from time to time.
Try the Application Request Routing addon for IIS to configure IIS as a reverse proxy.
Related
I was reading about http daemon and in order to make sense of it I tried to relate it to something I know and I thought that based on its definition it is very similar to IIS, so can we consider the IIS an HTTP daemon or does the IIS include it? I would appreciate it if anyone can clarify the relation between them.
Windows has a service called the HTTP Stack (http.sys) which is responsible for routing HTTP requests to the proper process, such as IIS.
When the IIS service runs, it registers any URLs that it wants to handle with http.sys. This makes it possible to have multiple processes share port 80 as long as they request different URLs.
I have two instances of Tomcat set up on two different servers. I didn't explicitly select which versions to install, they were actually both automatically installed as a part of IBM Rational Team Concert installations (v5.0.1 and v5.0.2 on each server), but I can say they are both at least version 7.
On the first instance, when I go to http://myserver.domain.com:9443/ccm, I get automatically redirected to https://myserver.domain.com:9443/ccm.
On the second instance, when I go to http://otherserver.domain.com:9443/ccm, I do not get redirected to https, but rather either get a strange download or get a blank page with an unrecognizable Unicode character (depending on the browser).
I notice that both server.xml's are different (I am not sure why RTC made them that different between minor releases), but it is not obvious by looking at them both what I have to set in the second server.xml to achieve the behavior present in the first. Port 9443 is set up as an HTTPS port. What do I set in server.xml to make all http requests to that port automatically redirect to https?
Tomcat can't do what you are asking. There is no mechanism to detect that http is being used on an https port and redirect the user accordingly. This might be something we add in Tomcat 9 but that is very much just an idea at this stage.
Something other than Tomcat is performing the redirect you observe. Take a look at the HTTP headers - they might provide some clue as to what is going on.
I'm writing a web app in Go. Currently I have a layout that looks like this:
[CloudFlare] --> [Nginx] --> [Program]
Nginx does the following:
Performs some redirects (i.e. www.domain.tld --> domain.tld)
Adds headers such as X-Frame-Options.
Handles static images.
Writes access.log.
In the past I would use Nginx as it performed SSL termination and some other tasks. Since that's now handled by CloudFlare, all it does, essentially, is static images. Given that Go has a built in HTTP FileServer and CloudFlare could take over handling static images for me, I started to wonder why Nginx is in-front in the first place.
Is it considered a bad idea to put nothing in-front?
In your case, you can possibly get away with not running nginx, but I wouldn't recommend it.
However, as I touched on in this answer there's still a lot it can do that you'll need to "reinvent" in Go.
Content-Security headers
SSL (is the connection between CloudFlare and you insecure if they are terminating SSL?)
SSL session caching & HSTS
Client body limits and header buffers
5xx error pages and maintenance pages when you're restarting your Go application
"Free" logging (unless you want to write all that in your Go app)
gzip (again, unless you want to implement that in your Go app)
Running Go standalone makes sense if you are running an internal web service or something lightweight, or genuinely don't need the extra features of nginx. If you're building web applications then nginx is going to help abstract "web server" tasks from the application itself.
I wouldn't use nginx at all to be honest, some nice dude tested fast cgi go + nginx and just go standalone library. The results he came up with were quite interesting, the standalone hosting seemed to be much better in handling requests than using it behind nginx, and the final recommendation was that if you don't need specific features of nginx don't use it. full article
You could run it as standalone and if you're using partial/full ssl on your site you could use another go http server to redirect to safe https routes.
Don't use ngnix if you do not need it.
Go does SSL in less lines then you have to write in ngnix configure file.
The only reason is a free logging but I wonder how many lines of code is logging in Go.
There is nice article in Russian about reverse proxy in Go in 200 lines of code.
If Go could be used instead of ngnix then ngnix is not required when you use Go.
You need ngnix if you wish to have several Go processes or Go and PHP on same site.
Or if you use Go and you have some problem when you add ngnix then it fix the problem.
I have created a sweet ASP.NET 4.0 UDP listener via WCF that starts on Application_Start. As usual, everything is hunky dory on my local machine. On my local machine using the VS Dev Environment and setting it to not open any page upon debug, the listener starts without browsing to anything yet. However, whenever I deploy to my shared host, I must access the site via a web browser before the listener will start. I do not have access to the IIS control panel but I do have some limited setting changes I can make to IIS via "Website Panel" software. I believe the shared host uses IIS 7.5.
Is there a better way to solve this rather than creating a polling service from my home PC to send an HTTP request to the shared host every so often to kick off the listener?
Requirements
The client sends UDP packets over a configurable port. I cannot change anything other than the IP and port that the client uses to connect
The solution must work with my shared host since I cannot afford a VPS at this time - otherwise I would've created a Windows Service. I got around creating a window service before by creating a polling service via WCF Application_Start but that only works because the info the users would see have to be on a webpage therefore application_start would always be called. In this case, the users/clients are not necessarily accessing the webpage.
Ideas:
Somehow pull this into a .svc. That way when the .svc is accessed by the client, it kicks off the listener for everyone else. But how can a .svc running on port 80 accept UDP calls? I'm also not sure if the client will be able to connect to more than an IP:PORT (I don't think it'd accept a .svc path like URL.com/awesomeListener.svc).
Any suggestions? Thank you so much.
If you are running ASP.NET 4.0 you can set it to auto-start for you which will fire Application_Start:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
We have an application built on ASP.NET MVC 1.0 which, once deployed, should be accessed with HTTPS. I tried few approaches for HTTPS but I have a few questions.:
My home page does not need to be Secured (HTTPS), but rest of the hyperlinks following it will be Secured.
I read about the action method attribute [requiresHTTPS] however I want to understand what happens to that tag during development on local machine.
In a development enviroment, how do I install a certificate on a dev machine/virtual directory to code and test my changes.
So this application is complex in nature and we have around 13 controllers and 50 action methods. This application will have information like Credit card numbers since we do accept payment through this website.
Thanks much !
If it is just about a few static pages of your application that don't need to be secured, I would strongly recommend to simply require SSL for everything by configuring two different sites in IIS, one for the actual page only on port 443, one on port 80 with a permanent redirect.
Advantages:
Your application and code doesn't have to know anything about SSL, and you don't need a SSL certificate on your dev machine. The web server does it all for you.
No cookie and HTTP caching mess with the HTTP/HTTPS flip-flop
If security/privacy matters, it's the best solution anyway to require SSL for all pages.
Regarding the possible disadvantage: serving a few requests on static resources via SSL is probably almost no overhead, compared to the rest of your application.