When One Slash Breaks the Web: Debugging an HTTPS Downgrade Bug

Introduction Recently, a seemingly small bug reported by a client spiraled into an unexpectedly deep dive into web protocols, redirection behavior, and server configurations. The issue? A folder URL without a trailing slash was mysteriously downgrading from HTTPS to HTTP.

The Problem The client’s website was hosted over HTTPS. However, accessing a specific path like:

https://example.com/QA

unexpectedly redirected users to:

http://example.com/QA/

On the other hand, if the URL already contained a trailing slash:

https://example.com/QA/

everything worked fine — no redirection downgrade, and users stayed securely on HTTPS.

This inconsistent behavior was a red flag, especially for secure applications or e-commerce platforms where HTTPS is non-negotiable.

Our Investigation We checked all the usual suspects:

• Apache Configurations: We combed through the httpd.conf, looking for misconfigurations in the VirtualHost, RewriteRules, or Redirect directives.

• .htaccess Files: We inspected the directory-level overrides for any rogue redirect rules.

• Server-Side Code: We ensured that no application logic was manually issuing HTTP redirects.

• SSL Certificates: Fully valid and up-to-date — no issues here.

But all configurations looked clean. No intentional redirection from HTTPS to HTTP was present anywhere.

Understanding the Behavior After extensive testing and packet captures, we discovered that the problem wasn’t rooted in the server intentionally downgrading protocols — it was in how the web server handled implicit redirects for directories without trailing slashes.

Apache, by default, performs a redirect to the canonical path with a trailing slash when accessing directories. But here's the catch: this redirection is handled by the server before the .htaccess rules are applied, and in certain setups (especially with name-based virtual hosting and non-default ports), Apache may issue the redirect using the default protocol — often HTTP.

The Culprit: A Missing Directive The fix was subtle but critical. We added the following directive to the Apache configuration:

UseCanonicalName On

And ensured proper rewrite rules were in place at the server level:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

These ensured that Apache would always redirect using the correct hostname and HTTPS protocol, regardless of whether the slash was present.

Takeaway Sometimes, the tiniest URL difference — like a missing slash — can lead to major protocol downgrades and security issues. This experience was a reminder that:

• Server defaults can cause unexpected behavior

• Redirect handling needs to be audited carefully

• It’s crucial to test both trailing and non-trailing slash versions of URLs in web apps

Final Thoughts What looked like a minor bug turned into an enlightening lesson in how web servers interpret requests. Always assume nothing — even slashes — and test everything.

---