In Hosting Services, we get custom requirements depending on project needs. I will share one such requirement that was unique in nature, considering the customer’s available infrastructure and the phase the project was in when the change request was raised.
The Challenge
On one of our website redesign projects – almost in the middle of development – the customer requested that two applications running on two different platforms be served as a single application, due to some SEO requirements. This customer was already hosting with us and was having two sites on two different platforms (one on IIS -Windows and the other on Apache-Linux).
The client’s corporate site was on IIS, and the store site was on Apache, and both were running by different domain names. They wanted the store site to appear as part of the corporate site and to be available as if it was a virtual directory of the corporate site (i.e., with “/store”). The customer was not willing to have the store site redesigned and integrated with or built into the corporate site, as their store site was stable and there was a time constraint; this could have delayed the project delivery by 3 to 6 months.
For the environments with a load balancer, this could have been an easy requirement, provided the servers are sitting in the same internal network segment. For this customer, all the servers were already in the same network segment; however, there was no load balancer in this environment. Again, provisioning the load balancer was a budgetary constraint, since such devices are generally used when there is need of multiple web servers for distributing the load OR a high availability (HA) requirement.
Implementing Application Request Routing (ARR)
To accomplish the request, since the corporate site was on IIS-Windows, we decided to use the Application Request Routing (ARR) extension of IIS. The following image depicts the proposed architecture.
For proof of concept (POC), we created a local setup with a copy of both the corporate and store sites. On the Windows server, we installed ARR and created a sever farm, with the Apache server being the only member. We configured a rewrite rule at the global level in IIS to route traffic for “/store” to this server farm and ultimately to the Apache server.
Resolving “404 Page not found” errors
The first issue we faced was the ”/store” pages throwing a “404 Page not found” error. Considering the applications and software installed on this server, and to isolate the issue, we used the code of a plain .Net site and noticed that we were not getting any more 404 errors.
We discovered that the CMS software that was installed to build the corporate site was not allowing ”/store” to open and was giving a ”404 Page not found error.” For the sites built with this software, we noticed that an exception needed to be added in the configuration settings to ignore the directory – in our case it was “/store.” Once this configuration change was made, the HTTP traffic started routing all requests for “/store” to the Apache server. Both sites were appearing as a single site, with “/store” being part of the corporate site.
Rerouting HTTPS traffic
Another hurdle that took some time to resolve was the routing of HTTPS traffic. Since ARR was playing the role of load balancer here, the secure sockets layer (SSL) certificate was terminated on the Windows server, making it listen on port 80(HTTP) and 443(HTTPS). The Apache server was set to listen on port 80 only. We were getting an infinite loop or “The page isn’t redirecting properly” error while accessing the HTTPS pages of “/store.”
We were aware the SSL header (X-ARR-SSL) was passing by the IIS server to Apache; however, the value for the header was starting with a number, and it was not constant. This was limiting the configuration done on the Apache server and causing the loop. After some trials in the Apache configuration, the HTTPS was set to “off” by default and the configuration changes were done in the .htaccess file to respond to this header treating it as an HTTPS request.
With this change, the secure pages also started working fine, with SSL being terminated at Windows server.
Resolving 502 errors from POST requests
The setup was released to QA and was going through their review. We were waiting for results in hopes of closing the POC. The QA reported another issue when they identified that POST requests to “/store” were throwing 502 errors.
With past learning of the aforesaid first issue, we again used a sample plain .Net site and tested the behavior. There were no 502 errors for POST requests. We concluded that again there was something within the CMS software that was causing this.
To troubleshoot and dig the issue further, we used the Failed Request Tracing feature of IIS to identify what was causing the 502 errors. Failed Request Tracing was enabled for the range near the HTTP error code 502, and it helped us identify a module that was part of the CMS application installed on the server. This module was causing the 502 errors on the POST requests. To confirm the findings, we commented out the module in the website’s configuration, which then stopped the 502 errors.
Since this module was of crucial importance to the corporate site, there was no scope to comment it out in the website configuration. A trouble ticket was raised with the CMS vendor, and they provided us a patch for the module. With this patch installed, there were no more 502 errors for POST requests.
Another round of QA took place, and this time the report was green! Thorough testing of the setup and site was done to release the POC to the client.
With the customer’s approval, the changes were deployed to production.
The redesigned site was delivered as per our plan and on time….. with ARR taking care of requests for “/store” in the production instance!
