First there was HTTP, then HTTP/2 and now HTTP/2 over the QUIC protocol. Lets have a look at the available HTTP Clients and Servers that support HTTP/2 and the experimental QUIC protocol. Introduction The Hypertext Transfer Protocol (HTTP) was invented in 1991. Up to 2015 then there was only little to no evolution. In 2015 the HTTP/2 protocol was defined as a standard. HTTP/2 is much more efficient that its ancestors. It features multiplexing, stream prioritization, binary transmission and much ….Read More
I was criticizing that software in RHEL is too outdated for web servers quite soon after release, see my blog post http://blog.delouw.ch/2010/05/02/rhel6-as-a-web-server/. While this is true for a system fully supported by Red Hat, I learned an alternative from a comment on the post. This alternative is the so called IUS community repository. About the IUS Community Project The project was launched in September 2009. In spite of being a young project, it has a history. At Rackspace, a large ….Read More
The Apache httpd is one of the most stable software pieces which is still in use. The latest huge step forward was with the release of 2.0. Quo vadis Apache httpd? The most current release is 2.2.15. During the 2.2.x release cycle, there have basically been only bug-fix releases (Okay, response header rewrite starting on 2.2.9 is a nice feature). This brings me to the question: What is going on with 2.4? The answer is quite simple: As you can ….Read More
New software versions Today I’m writing about the changes and benefits of RHEL6 as a web server compared to RHEL5. Red Hat is well known for its stable API and ABI over the life-cycle of a major release. For some usage types this is a major problem. Sticking to old version of PHP, MySQL, Tomcat you-name-it-piece-of-software is problematic since web applications are rapidly changing its requirements. Instead of PHP 5.1.6, RHEL6 ships almost up-to-date PHP 5.3.1. Which is good, since ….Read More
You have a web site all with SSL. There is a reverse proxy or load balancer that acts as SSL termination point. Behind that reverse proxy you have an Apache web server running plain http.
Your application uses 302 redirects to announce new URLs or whatever the reason is for doing so. Since the web server does not know that https URLs should be announced the response header looks like following:
The browser interprets that location header and send a request to this non-SSL URL instead of https://