[HTACCESS] alles naar https

Accepteert het certificaat wel wildcards?

Probeer eens als volgt:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nee dat gaat niet @Arien

Ja sinds kort wordt het ondersteund, naar lang zeuren en zonder mededeling :/ @Thomas

Werkt wel voor http://domein.com (Gaat gelijk naar https), maar niet voor de andere mappen (http://www.domein.com, http://sub.domein.com). @Ozzie

Edit: Volgens websniffer werkt ie trouwens helemaal niet. Terwijl t in de browser wel werkt.

Het klinkt meer en meer alsof er mogelijk (server?)configuratie is op specifieke subdomeinen die roet in het eten gooien. Of wellicht logica in de websites zelf die zorgen voor redirects, wellicht hard-coded hyperlinks die geen rekening houden met een ander protocol (https)?

Een of meer van de bovenstaande .htaccess varianten zouden gewoon moeten werken, al ontbreekt er misschien een [OR] achter de eerste RewriteCond in je twee eigen poging. Ik zou vervolgens per (sub)domein gaan kijken wat er aan de hand is. En misschien een hulptool zoals @Ariën voorstelt gebruiken om te kijken wat er precies gebeurt.

@Ozzie, dat werkt wellicht wel, maar misschien is dit niet echt de goede insteek; voor zover ik weet is het prima mogelijk om https via poort 80 te laten verlopen, al is het ongebruikelijk (en misschien andersom ook? geen idee). Een controle op een poort voor de bepaling van het gebruikte protocol (ook al wordt een protocol vaak geassocieerd met een standaard poort) is daarom misschien minder verstandig, het staat in zekere zin los van elkaar.

>> Een controle op een poort voor de bepaling van het gebruikte protocol is daarom misschien minder verstandig.

Als het ene niet werkt zul je wat anders moeten proberen. Poort 80 is de standaardpoort voor HTTP en normaliter zal die niet wijzigen, tenzij je dit zelf bewust doet. Als dit werkt lijkt het me dus een prima oplossing.

@Michael

Probeer deze eens:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

Ozzie PHP op 13/10/2020 14:12:14

Poort 80 is de standaardpoort voor HTTP en normaliter zal die niet wijzigen, tenzij je dit zelf bewust doet.

Dat klopt, maar de RewriteRules zouden moeten controleren of HTTPS wel of niet actief is. Dit heeft in principe niets met poortkeuze te maken.

Je kunt niet constateren dat iets een appel is als het geen peer is... en daarom zou je die dus ook niet met elkaar moeten vergelijken :p.

Mijn oplossing (als die werkt) volstaat gewoon prima Thomas. Niet iedere server geeft alle gewenste variabelen mee en dan zul je soms flexibel naar andere oplossingen moeten kijken. Poortnummer volstaat in dit geval prima. Een appel en een peer zijn dan ook niet van toepassing.

Ozzie PHP op 13/10/2020 22:57:14

Mijn oplossing (als die werkt) volstaat gewoon prima Thomas.

Simpelweg omdat iets werkt maakt het nog niet juist. Het bovenstaande is ook geen opzet die ik naar andere servers zou dupliceren. Als je wilt weten of HTTPS actief is... controleer dan gewoon op het actief zijn van HTTPS? Ik zou zeggen, als je dat niet makkelijk kunt doen dan is er waarschijnlijk meer aan de hand.

Ozzie PHP op 13/10/2020 22:57:14

Niet iedere server geeft alle gewenste variabelen mee en dan zul je soms flexibel naar andere oplossingen moeten kijken.

Mja, soms zal dat inderdaad moeten, maar dan ben je al bezig met workarounds. In dit geval weet niemand nog precies wat er misgaat. Voordat je een remedie voorschrijft/toepast zul je toch echt eerst moeten weten wat de patiënt mankeert. Ik zou daarom eerst eens kijken wat er allemaal gebeurt tussen request en de uiteindelijke response. Op dit moment is daarvan nog niet echt een analyse?

Wanneer meerdere gangbare oplossingen in .htaccess niet direct werken dan lijkt het mij tijd om je horizon wat te verbreden om te zien wat daarbuiten nog allemaal gebeurt en ligt het waarschijnlijk niet (uitsluitend) aan .htaccess. Daar dan proberen een toverformule voor te vinden die voor alle cases werkt is wellicht niet zo verstandig, omdat je dan nog steeds niet weet wat er precies misgaat.

Dit moet gewoon (uitgezocht en) opgelost worden, het is niet aan .htaccess om dit recht te breien als er elders kinken in de kabel zitten / fouten zitten in de overige configuratie.

Ozzie PHP op 13/10/2020 22:57:14

Poortnummer volstaat in dit geval prima. Een appel en een peer zijn dan ook niet van toepassing.

Okay, als je blijft volhouden dat een poortnummer en het protocol een en hetzelfde ding zijn en dus ook in het gebruik uitwisselbaar zijn dan zijn we min of meer klaar denk ik.

Wat ik zeg / probeer te zeggen, is dat op een normaal ingerichte server HTTP altijd op poort 80 draait en HTTPS op poort 443. Dat is iets wat altijd zo is, tenzij je dit zelf om een of andere reden hebt gewijzigd. Je kunt dus gewoon kijken of er een signaal binnenkomt op poort 80. Theoretisch zijn een poort en een protocol niet hetzelfde, maar in de praktijk kun je deze oplossing gerust toepassen. Ja, protocol afvangen heeft de voorkeur, maar als je bij een of andere exotische host zit waardoor die servergegevens niet voorhanden zijn, kun je uitwijken naar poortdetectie. Daar is niks mis mee. Ik zeg niet dat het de voorkeur verdient boven vaststellen van het protocol. Het is simpelweg een praktische oplossing, een alternatief.