url met slash geeft problemen

Heb je een .htaccess met een bijzondere regel?

Nee ik heb wel een .htaccess bestand maar alleen voor het gebruik van ssl certificaat

Het kan ook in die regel zitten, als je daarin doorstuurt.
Heb je anders een voorbeeld? Wat relevante code?

Ik heb de .htaccess code klakkeloos overgenomen van hostingprovider en dat ziet er alsvolgt uit:

RewriteEngine On 
RewriteBase /
#Do not redirect .well-known
RewriteCond %{REQUEST_URI} !^/\.well\-known/
RewriteCond %{HTTP:X-Forwarded-Proto} !https [NC] 
RewriteCond %{HTTPS} off [NC] 
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=302] 

Zit het dan niet in je code?
Laat eens zien welke site is het?

Ik denk dat dit eerder een serverconfiguratie dingetje is.
Mijn site doet dit ook, maar zie dat phphulp dat weer niet doet.

Edit:
Het probleem zal erin zitten dat ie het dan als map zit, en je pad naar je css etc. dus niet meer klopt. Als je het volledige pad gebruikt werkt het wel.
Verder zou ik me er niet zo druk om maken ;-)

Ik maak me er toch wel een zorgen over, omdat google search console die pagina's met een slash niet meer indexeert. Ik weet niet of dezelfde pagina's maar dan zonder '/' wel of niet door google worden geindexeerd.

Maar een slash hoort ook niet achter een URL. Browsers strippen die ook vaak.

Mark Coenie op 15/03/2019 11:10:19

Echter ben ik er net achter gekomen dat als ik de absolute url van een subpagina in de adresbalk invoer met een slash erachter dat alle link bestanden zoals css en javascript bestanden niet aan de pagina worden gekoppeld.
voorbeeld: https://domeinnaam.com/subpagina.php/

Maar dit doe je dus zelf, bij wijze van test. Is een reden om aan te nemen dat anderen de website zo aanspreken? En zoals @Michael aangeeft: een volledig pad voor verwijzing naar de bron zorgt ervoor dat dit altijd werkt.

Dan is er eigenlijk nog een ding wat niet klopt en dat is dat /subpagina.php/ in zekere zin een ongeldig verzoek is. Het is in dit geval immers geen directory maar een bestand.

Als dit niet de bedoeling is (en/of wanneer het incorrect aanroepen van een pagina jouw site effectief breekt of de werking ernstig belemmert) zou je hier een RewriteRule voor aan kunnen maken om het verwijderen van de slash te forceren, maar normaal gesproken zou je eigenlijk nooit in deze situatie verzeild raken tenzij iets of iemand zelf bewust van het getreden pad afstapt.

Ook zou er een soort van eenduidige controle moeten zijn of een aanroep juist of onjuist is, en in het laatste geval zou je eigenlijk gewoon een 404 pagina moeten serveren. Dat is eigenlijk nog het beste omdat dat zowel aan menselijke alsook mechanische bezoekers vertelt dat het verzoek onjuist was. En het is tevens de simpelste oplossing. Je kunt namelijk dingen blijven bedenken die bezoekers kunnen uitspoken in de aanroep naar een webpagina. Veel succes met het afvangen van al die gevallen :).

- Ariën - op 15/03/2019 16:08:11

Maar een slash hoort ook niet achter een URL.

Toch wel als je een directory aanspreekt? En ook heeft dit (dus) implicaties voor relatieve verwijzingen naar stylesheets, afbeeldingen et cetera. Het toevoegen of weglaten ervan betekent een directory verschil in het relatieve pad. Nu kun je dit probleem uit de weg gaan door overal absolute verwijzingen te gebruiken (waar ik voorstander van ben omdat dat compleet ondubbelzinnig is) maar dat neemt dus niet weg dat een slash wel degelijk valide is en ook betekenis heeft.

- Ariën - op 15/03/2019 16:08:11

Browsers strippen die ook vaak.

In de adresbalk wellicht, maar toch niet in het daadwerkelijke HTTP request? Tenzij het echt een bestand betreft?

Dat moet ik nog eens testen. In paden is deze wel van belang.
Ik denk dat de browsermakers wel een reden hebben om die / te strippen.