Internal Server Error na aanpassing in .htaccess

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Jan Volker

Jan Volker

02/05/2019 20:23:21
Quote Anchor link
Beste ,

Ik probeer via .htaccess in te stellen dat `.php?id= niet wordt weergegeven in de URL. Ik probeer dit te realiseren met de volgende regel:
RewriteRule ^Change/(.*)$ Change.php?id=$1 [L]

Mijn verwachting hiermee is dat wanneer ik navigeer naar:
www.mijndomeinnaam.nl/map/Change/abc123

De inhoud van de volgende pagina te zien krijg:
www.mijndomeinnaam.nl/map/Change?id=abc123

Echter, is dit niet het geval. Wanneer ik hier naar navigeer krijg ik een Internal Server Error (The server encountered an internal error or misconfiguration and was unable to complete your request).

Mijn .htaccess ziet er als volgt uit:

Quote:
RewriteEngine on
RewriteRule ^Change/(.*)$ Change.php?id=$1 [L]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.+?)/?$ $1.php [L]

php_value session.cookie_domain .mijndomeinnaam.nl


Weet iemand toevallig waar dit aan ligt?
Gewijzigd op 02/05/2019 20:24:03 door Jan Volker
 
PHP hulp

PHP hulp

15/11/2024 00:30:24
 
- Ariën  -
Beheerder

- Ariën -

02/05/2019 20:51:54
Quote Anchor link
Heb je al in je error_log gekeken?
 
Jan Volker

Jan Volker

02/05/2019 21:41:53
Quote Anchor link
Hoi Ariën,
Daar heb ik al in gekeken. Ik weet alleen niet of de melding te maken heeft met .htaccess. Meest recente regel uit error_log is:
[Thu May 02 00:11:01.878760 2019] [core:notice] [pid 3230] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'

Toevoeging op 02/05/2019 21:46:13:

Dit is trouwens een Apache Error Log (var/log/httpd/error_log)
 
Thomas van den Heuvel

Thomas van den Heuvel

02/05/2019 22:21:28
Quote Anchor link
Als Apache in CGI-modus draait, wat blijkbaar aanbevolen wordt, werken de directives php_value en php_flag niet in .htaccess bestanden, deze veroorzaken dan Internal Server Errors.

Je kunt een php.ini gebruiken, een .user.ini (?) in je webdirectory (let op initiele punt) gebruiken, of simpelweg het .htaccess bestand gebruiken, maar dan met de .ini-opmaak:
<setting> = <value>
bijvoorbeeld
upload_max_filesize = 2M

oftewel, probeer eens "php_value" te verwijderen.
Gewijzigd op 02/05/2019 22:22:12 door Thomas van den Heuvel
 
Jan Volker

Jan Volker

02/05/2019 22:29:21
Quote Anchor link
Ik had al geprobeerd om php_value te verwijderen. Hetzelfde geldt voor de regels die betrekking hebben op .php.

Ondanks dat ik deze regels verwijder blijf ik dezelfde melding krijgen.
 
Thomas van den Heuvel

Thomas van den Heuvel

02/05/2019 22:43:40
Quote Anchor link
Dan is het misschien handiger om dingen regel per regel te verwijderen om te zien wat de boosdoener is.

Wat je nog kunt proberen is .php achter %{REQUEST_FILENAME} te verwijderen, volgens mij hoort die extentie daar niet thuis.

En moet dat niet !-f zijn? Tenzij al je PHP-scripts in de webdirectory staan, wat in geval van gebruikmaking van rewriterules mogelijk niet echt handig is, omdat je dan "botsingen" kunt krijgen tussen virtuele namen en bestaande bestanden?

Daarnaast is het ook handiger om alles naar één script te sturen - nu heb je tig "voordeuren" in je applicatie, het is handiger om slechts één enkele voordeur (single point of entry) te hebben.
 
Ivo P

Ivo P

03/05/2019 10:55:06
Quote Anchor link
Quote:
RewriteRule ^Change/(.*)$ Change.php?id=$1 [L]

Mijn verwachting hiermee is dat wanneer ik navigeer naar:
www.mijndomeinnaam.nl/map/Change/abc123


nee. Want door de ^ zeg je, dat het path moet _beginnen_ met Change. En in jouw voorbeeld begint dat met "map"
 
- Ariën  -
Beheerder

- Ariën -

03/05/2019 11:33:27
Quote Anchor link
Thomas van den Heuvel op 02/05/2019 22:21:28:
Als Apache in CGI-modus draait, wat blijkbaar aanbevolen wordt, werken de directives php_value en php_flag niet in .htaccess bestanden, deze veroorzaken dan Internal Server Errors.

Je kunt een php.ini gebruiken, een .user.ini (?) in je webdirectory (let op initiele punt) gebruiken, of simpelweg het .htaccess bestand gebruiken, maar dan met de .ini-opmaak:
<setting> = <value>
bijvoorbeeld
upload_max_filesize = 2M

oftewel, probeer eens "php_value" te verwijderen.

Klopt, maar op servers valt ook 'htscanner' te installeren die deze php-flags wel in deze situatie laten werken in .htaccess. Ik weet dat DirectAdmin ervan voorzien is ;-)
Gewijzigd op 03/05/2019 11:33:42 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

03/05/2019 16:51:29
Quote Anchor link
- Ariën - op 03/05/2019 11:33:27:
Klopt, maar op servers valt ook 'htscanner' te installeren die deze php-flags wel in deze situatie laten werken in .htaccess. Ik weet dat DirectAdmin ervan voorzien is ;-)

Maar waarom zou je een extra mod aanbrengen die een .htaccess patcht? :/
Gebruik gewoon syntax die direct werkt.
 
- Ariën  -
Beheerder

- Ariën -

03/05/2019 17:02:57
Quote Anchor link
Omdat niet iedereen veel kennis heeft, en php_flags vroeger veel gebruikt werden.
 
Thomas van den Heuvel

Thomas van den Heuvel

03/05/2019 17:16:08
Quote Anchor link
Geen van beide is een excuus, noch een sterke reden. Fix de syntax gewoon, probleem opgelost.
Gewijzigd op 03/05/2019 17:19:49 door Thomas van den Heuvel
 
- Ariën  -
Beheerder

- Ariën -

03/05/2019 17:22:05
Quote Anchor link
Ik snap je punt, maar leg dat maar uit aan een simpel iemand die een kant-en-klaar pakket heeft, of zijn website overkopieert naar een andere server.
 
Thomas van den Heuvel

Thomas van den Heuvel

03/05/2019 19:29:16
Quote Anchor link
<specifiek geval waarin een pleister handig kan zijn> => <de pleister zou overal toegepast moeten worden>

Nee.

Anyhow, @Jan, comment gewoon de regels in je .htaccess totdat je de boosdoener hebt, dat lijkt mij de eenvoudigste manier.
Gewijzigd op 03/05/2019 19:35:00 door Thomas van den Heuvel
 
- Ariën  -
Beheerder

- Ariën -

03/05/2019 19:57:02
Quote Anchor link
Tja, het is nu eenmaal zo,Thomas. Als jij het via php.ini op wilt lossen, ook prima. Er leiden soms meerdere wegen naar Rome waarvoor iemand uiteindelijk kiest: de ene via de snelweg, en de andere via een langere binnenweg.
Maar goed, laten we weer on-topic gaan.
Gewijzigd op 03/05/2019 20:17:21 door - Ariën -
 
Jan Volker

Jan Volker

03/05/2019 22:06:58
Quote Anchor link
Ivo P op 03/05/2019 10:55:06:
Quote:
RewriteRule ^Change/(.*)$ Change.php?id=$1 [L]

Mijn verwachting hiermee is dat wanneer ik navigeer naar:
www.mijndomeinnaam.nl/map/Change/abc123


nee. Want door de ^ zeg je, dat het path moet _beginnen_ met Change. En in jouw voorbeeld begint dat met "map"


Oke duidelijk. Als ik het goed begrijp zou het dus moeten werken als ik dit aanpas naar: RewriteRule ^map/Change/(.*)$ map/Change.php?id=$1 [L]

Klopt dat?

Ik heb het in dit geval uitgeprobeerd, ook hier krijg ik dezelfde melding.

------

Correctie:

Het blijkt dus wel te werken. Het vreemde is alleen dat de elementen op deze pagina meerdere keren geladen worden. Om even een voorbeeld te noemen. Ik heb één `tekstveld` op mijn pagina. Wanneer ik de website open via: `map/Change.php?id=abc123` krijg ik deze tekstveld te zien.

Deze pagina blijft laden.

5 seconden later heb ik twee tekstvelden
20 seconden later staan er 5 tekstvelden
1 minuut later staan er 10 tekstvelden

Kan dit te maken hebben met de .htaccess?

Het vreemde is wel dat hij dit niet doet als ik de pagina via ?id= open
Gewijzigd op 03/05/2019 22:24:53 door Jan Volker
 
Thomas van den Heuvel

Thomas van den Heuvel

04/05/2019 00:46:58
Quote Anchor link
> Kan dit te maken hebben met de .htaccess?
Geen idee, wat doet de code in Change.php?

Heb je toevalling meerdere Change.php scripts in meerdere directories? Heb je toevallig meerdere .htaccess bestanden? Ontbreekt er mogelijk een RewriteBase?

Als het id wat je verwacht numeriek zou moeten zijn, dan zou ik kijken of de invoer ook numeriek is.

Om echt duidelijk te krijgen wat er nu precies aan de hand is zou ik alle overige dingen even uitcommenten, zoals die tweede rewriterule, die gooit misschien roet in het eten.

Het lijkt mij nog steeds makkelijker om dingen meer te delegeren, bijvoorbeeld door alles eerst door te sturen naar index.php. In index.php wil je iets van de vorm /map/Change doen, gooi het over de schutting naar /een/of/andere/interne/directory/map/Change.php, het script dat dit verzoek verder zou moeten afhandelen. Daar zie je dat dat ding nog een argument heeft waar Change.php iets mee kan.

Als je een integrale/uniforme aanpak hebt voor de routing (b)in(nen) je applicatie garandeer je ook veel beter dat je dingen makkelijker kunt compartimenteren en dus ook in afzondering kunt debuggen zonder inmenging van allerlei andere zaken.
 
Ivo P

Ivo P

04/05/2019 14:38:36
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
RewriteEngine on
RewriteRule ^Change/(.*)$ Change.php?id=$1 [L]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.+?)/?$ $1.php [L]


Je roept aan /map/Change/abc123

Regel 2 gaat niet af, want je begint niet met Change.

Dus herschrijf je dit naar
/map/Change/abc123.php

Naar verwachting bestaat die file niet.
Nu zou je daar een 404 kunnen krijgen, wegens "is er niet", of je duikt opnieuw door die routine
en herschrijft dit naar /map/Change/abc123.php.php
en dan naar /map/Change/abc123.php.php.php

Tot Apache het wel mooi geweest vindt.

TIP: check op z'n minst even of er niet al ".php" in je filename staat voor je blint herschrijft.
(dit gaat trouwens ook op, voor de situatie waarbij bijvoorbeeld logo.gif niet blijkt te bestaan.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.