Ich habe gerade Stunden damit zugebracht, für meinen pgp.asc Publickey (pgpasc.org) sicherzustellen, dass er nur per https ausgeliefert wird, selbst wenn man ihn unter http aufruft.

Klingt erstmal nach einer einfachen Aufgabe, htaccess, ein paar Conditions, Weiterleitung - fertig.

So dachte ich bereits vor einigen Monaten, bekam es nicht gleich hin und habe es dann erstmal liegen lassen. Heute gab ich nicht so schnell auf, obwohl ich mehrfach kurz davor war, denn hier bei meinem Setup wollte das einfache Modell par tout nicht greifen.
Wohl, weil ich kein eigenes Zertifikat für die Domain "webrocker.de" habe - eine einfache Weiterleitung auf "https://webrocker.de" würde zwar gehen, aber zu Warnungen im Browser des Besuchers führen. Mein Provider, DomainFactory, bietet die Möglichkeit, via "https://sslsites.de/[domainname]/..." Inhalte per https auzuliefern, ohne, dass da ein Zertifikate/Domain-Missmatch im Browser angemeckert wird.

Das klappt normalerweise auch alles super, aber wenn man versucht, eine Adresse wie http://webrocker.de/pgp.asc auf https://sslsites.de/webrocker.de/pgp.asc umzubiegen, erlebt man Überraschungen.
Egal, was ich angestellt habe - der Redirect führte zu ständigen "too many recursions" Fehler und einem Abbruch des Verbindungsaufbaus.

Ich habe das nicht verstanden, denn in meinen htaccess Konditionen überprüfte ich auf:

RewriteCond %{REQUEST_URI} ^pgp\.asc #- Ist die angefragte Adresse der Key?
RewriteCond %{HTTP_HOST} !^sslsites\.de #- Kommt die Anfrage von webrocker.de, nicht sslsites.de?
RewriteCond %{HTTPS} off #- Ist http inaktiv?
RewriteCond %{HTTP_PORT} #- Ist Port 80, also http?
AddType text/plain asc #- .asc als Text zurückgeben (wird sonst ggf zum DL angeboten)
RewriteRule ^pgp\.asc https://sslsites.de/webrocker.de/pgp.asc #- nur Umleiten, wenn obiges greift

Diese Bedingungen, egal welche und welcher Kombination, waren anscheinend immer wahr - und so wurde die weitergeleitete Seite wiederum weitergeleitet, und weitergeleitet und weitergeleitet - bis zum Timeout bzw Fehlermeldung wegen "too many recursions". :-/

Ich habe nach mehreren Runden Suchmaschine und StackOverflow-driven development dann eine Datei auf dem Server abgelegt, in der ich die "$_SERVER" mitloggte - und das brachte dann schliesslich die Erkenntnis, das auch nach der Weiterleitung auf "sslsites.de/webrocker.de/..." die ganzen Variablen wie "HTTP_HOST", "SERVER_PORT" so gesetzt waren, wie vor der Weiterleitung. Am überraschendsten fand ich, dass, obwohl in der Browser-Adressleiste "sslsites.de/webrocker.de/pgp.asc" zu sehen war, der "HTTP_HOST" im Log weiterhin "webrocker.de" lautete - damit war schon mal klar, warum der Bedingung auf HTTP_HOST aus der htaccess nicht greift. Der Port im Log war "80", über HTTPS stand gar nichts in den $_SERVER Variablen - alles also nach der Weiterleitung genau wie davor – keine "meiner" Kontrollbedingungen konnte greifen. Mööp.

Ich habe dann die Logdatei per http und https aufgerufen und die protokollierten Einträge verglichen, und schliesslich die Variablen "HTTP_X_FORWARDED_HOST" und "HTTP_X_FORWARDED_SERVER" entdeckt, in denen in der https Variante "sslsites.de" drinstand und die in der http Variante nicht gesetzt waren.
Aha!

Es dauerte dann noch ein paar Suchmaschinenrunden und dann hatte ich die entsprechende htaccess Kondition gefunden: "%{HTTP:X-FORWARDED-HOST}"(und %{HTTP:X-FORWARDED-SERVER}) und damit klappt es nun endlich:

RewriteEngine On
RewriteBase /
 
# pgp.asc nur ueber https
RewriteCond %{HTTP:X-FORWARDED-SERVER} !^sslsites.de [NC]
AddType text/plain asc
RewriteRule ^pgp\.asc https://sslsites.de/webrocker.de/pgp.asc [L,R=301]