0

I've never seen this before and Google didn't lead to any results so far. I am almost sure it is a mistake so stupid that I should see it but I just don't.

I have a very basic Apache server with PHP, it serves the PHP files just fine for years, no issues. However, I just discovered, that if you add a %20 after the .php in the URL (for example https://www.example.com/index.php%20), Apache serves the file as plain text instead of serving a 404 page.

My conf for the php module seems fine and I really could not find any piece of information when googling for the issue.

Contents of my /etc/apache2/mods-enabled/php5.conf

<IfModule mod_php5.c>
  AddType application/x-httpd-php .php .phtml .php3
  AddType application/x-httpd-php-source .phps
</IfModule>

Apache version is 2.2.22 running on Debian Wheezy

Anyone ever seen this happening and knows what magic setting I have to tweak to stop Apache from doing this and instead serve a 404 page?

4
  • What is your php version ?
    – Froggiz
    Commented Nov 29, 2015 at 22:42
  • It is v5.2 (Zend Engine 2.2 if that makes a difference) Commented Nov 29, 2015 at 22:47
  • Wheezy comes with PHP 5.4, so you're running a severely out-of-date and likely to be extremely insecure version of PHP. Re-test on a supported-by-someone version of PHP, with a minimal reproducible test case.
    – womble
    Commented Nov 30, 2015 at 1:07
  • Unfortunately I have to stick with PHP 5.2 on this system due to a dependency not being compatible with newer versions :( Commented Nov 30, 2015 at 8:18

1 Answer 1

1

Try this, replace your current with this:

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

Then restart apache and see if that fixes it. I don't know if it will, my guess is it won't, but give it a try just to see, it's a more precise rule anyway.

But it looks to me like something in apache is not properly handling urls with a space, I tested this on my local system just to see, and when I requested:

"mysite.com/test.php "

Apache correctly rewrites it internally to

"mysite.com/test.php"

So there's I believe almost certainly another configuration that is off. But try the above and see.

Make sure to comment your stuff first, then add this in. There's probably syntax differences from 2.2 because I'm running apache 2.4, which if I remember right had a bunch of small differences in the debian configurations that led to a lot of issues, but I don't remember what they were.

I believe you can fully exclude php from this, the issue appears to be with apache2.2 and how it's handling urls, I've had this apache install for a long time, and I know I've neither added or removed any configuration that would create that situation., so you probably want to review very carefully any other non php configuration changes you might have made since installation.

The one time I have seen php code in its unparsed form on the page it was always due to the php engine not actually being correctly configured, but that's not your case since this only occurs with a space after the .php, so your php itself is fine.

As a short term hack, but NOT a solution, you can do a rewrite rule, which is very simply this:

RewriteRule ^(.*)([[:space:]]|%20)+$ /$1 [R=301,L]

I can't test this because I don't have any apache that fails to handle spaces / %20 at the end of the urls, nor do I know how to make that happen.

The rule simply says, take all spaces at the end of the line and dump them, and redirect to the actual url. Note that there are probably better ways to do this, again, it's not a situation I've ever come across so I don't know the best practices.

2
  • Approach 1 actually didn't work for me so I went with the rewrite rule for now until I can either find a proper solution or, preferably, update the system to the latest and greatest versions of everything, thanks for the comprehensive answer! Commented Nov 30, 2015 at 16:01
  • 1
    If you by chance find the real solution as to why apache wasn't trimming off the spaces, can you post it as a comment here, I'd like to know how that happens, or rather, what makes that default behavior not happen. I looked all through my configurations and couldn't find anything obvious. I had little confidence that method 1 would work, so it's good to see it didn't.
    – Lizardx
    Commented Nov 30, 2015 at 19:35

Not the answer you're looking for? Browse other questions tagged .