url met slash geeft problemen
Ik programmeer zelf geen php maar ik schrijf mijn websites wel in php bestanden.
Ik doe dat omdat dat enkele voordelen heeft zoals het gebruik maken van includes.
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/
Alle javascript bestanden werken dus niet en de pagina wordt alleen in html vorm weergegeven. De css stijlen zijn dus ook niet zichtbaar op de pagina.
Zijn er meer mensen met dit probleem en is het op te lossen?
Gewijzigd op 15/03/2019 22:59:13 door Fester Splinter
Heb je anders een voorbeeld? Wat relevante code?
Gewijzigd op 15/03/2019 12:03:41 door - Ariën -
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
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]
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]
Laat eens zien welke site is het?
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 ;-)
Gewijzigd op 15/03/2019 14:13:30 door Michael -
Gewijzigd op 15/03/2019 19:25:16 door - Ariën -
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/
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?
Gewijzigd op 15/03/2019 19:39:17 door Thomas van den Heuvel
Ik denk dat de browsermakers wel een reden hebben om die / te strippen.
Gewijzigd op 15/03/2019 19:46:41 door - Ariën -
Quote:
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.
Het betreft hier een pagina die wel weergegeven wordt alleen zonder werkende css en javascript. 404 is hier niet van toepassing.
Ik heb hieronder 2 links geplaats om duidelijk te maken wat ik precies bedoel:
https://background-tiles.com/overview/patterns.php
https://background-tiles.com/overview/patterns.php/
Gewijzigd op 15/03/2019 20:28:18 door Fester Splinter
Mark Coenie op 15/03/2019 20:14:16:
Mja, maar "patterns.php" is geen directory. Oftewel, deze pagina bestaat niet.
Maar nogmaals, wie roept die pagina zo aan? Alleen jij zelf? Is dit een wijder verbreid probleem? Ik zou eerlijk gezegd geen moeite doen om proberen recht te buigen wat krom is, noch te "second guessen" welke pagina iemand dan wel zou willen zien.
Een URL klopt, of deze klopt niet. En zoals aangegeven kun je het serveren van CSS- JavaScript- en andere bestanden in goede banen leiden door absolute URL's te gebruiken. Een base-tag kan ook een oplossing zijn als je overal relatieve verwijzingen gebruikt.
Gewijzigd op 15/03/2019 20:38:56 door Thomas van den Heuvel
Quote:
Maar nogmaals, wie roept die pagina zo aan? Alleen jij zelf? Is dit een wijder verbreid probleem? Ik zou eerlijk gezegd geen moeite doen om proberen recht te buigen wat krom is, noch te "second guessen" welke pagina iemand dan wel zou willen zien.
Het geeft problemen in google/ search console/ dekking.
pagina's worden uitgesloten. En alle pagina's die zijn uitgesloten staat die slash erachter.
Toevoeging op 15/03/2019 22:57:30:
Quote:
Gebruik je een base-tag?
Nee ik gebruik geen base-tag. Hier heb ik ook geen ervaring mee.
Mark Coenie op 15/03/2019 22:52:32:
Het geeft problemen in google/ search console/ dekking. pagina's worden uitgesloten. En alle pagina's die zijn uitgesloten staat die slash erachter.
Reden te meer om niet-bestaande pagina's een 404 status te geven? Daarmee markeer je dat soort pagina's ook echt als niet-bestaand. Dit lijkt mij de enige manier om dit probleem de wereld uit te helpen want iedereen kan op elk moment besluiten om een of andere onzinpagina aan te roepen.
Google helpt je vast wel om het verschil tussen die twee uit te leggen ;-)
Het beste zou je zgn "root relative paths" kunnen gebruiken. Die beginnen met een slash. De domeinnaam en het protocol (http of https) is dan relatief. Een voorbeeldje: /javascript/jquery.js "root relative paths" beginnen altijd met een slash.
Gewijzigd op 16/03/2019 01:52:13 door Frank Nietbelangrijk
Quote:
Dan heb je in ieder geval een basis voor alle relatieve URL's.
Ik heb wel al gegoogeld maar het is me niet helemaal duidelijk hoe ik een base-tag moet gebruiken.
Moet ik in elke folder een basis pagina aanmaken en dan alle in alle pagina's in die folder een base-tag plaatsen naar die basispagina?
Maar in mijn geval staat er in de base-tag op mijn hele site dit:
Code (php)
1
<base href="http://www.website.nl/layout/">
Waarbij in de map /layout dus alle afbeeldingen,javascripts en stijlen staan (verdeeld in verschillende mappen)
Maar je kan er ook voor kiezen om alle statische onderdelen van je site via een aparte domein of CDN te laten sluizen. Dat scheelt weer wat snelheid in de HTTP-requests. Grotere sites doen zoals Facebook, Tweakers, Twitter etc doen dat ook, bekijk als voorbeeld maar de URL waar ze hun plaatjes vandaan serveren. Ook heeft dit als voordeel dat ze voor de statische content een lichtere webserver kunnen gebruiken.
Gewijzigd op 16/03/2019 14:44:02 door - Ariën -