0

I have a very simple, minimal PHP-based page running on my Apache server, that loads perfectly fine from various computers, operating systems, and web browsers. The PHP version is 7.4.33, Apache Server version: Apache/2.4.56 (Raspbian).

But a few people reported that when they try to access it, they see the raw PHP code instead of a web page. These seem to be iOS users who are using either/both Safari and/or Chrome. I have searched for previous questions on SO but only found one related post but it didn't apply in my case -- most of the time the full page is displayed, only certain iOS devices see the code.

The code itself is very simple. It loads a header and a footer which are each .php files but contain mere HTML*:

<?php
  include 'header.php';
  include 'footer.php';
?>

The above is what some iOS users see instead of the proper page. I reproduce this problem on my iPad (iPadOS 16.6, Safari, Chrome, and/or Brave), but it works fine on my iPhone (iOS 16.6) on which I see the page normally (Safari).

Clearing cookies/cache, starting in private mode, trying yet another browser, all fail to help on the iPad. Also adding some explicit header language like header("Content-Type: text/html; charset=UTF-8"); to the PHP doesn't help.

How can I help these users? This doesn't strike me an Apache config error, because it loads fine on all other devices/browsers/etc (but maybe it is?). Thus, is it Apple-related somehow?

* Example:

    $ cat header.php 
    <center><h2>Welcome to the page</h2></center>
sh37211
  • 1,411
  • 1
  • 17
  • 39
  • It's a server-related issue, Apache doesn't render the php page correctly. Do you use any `.htaccess` with special rules? Is there any useful info in Apache's access/error logs? – Alberto Fecchi Aug 28 '23 at 22:39
  • Clarification: Apache renders the PHP page correctly to all but certain few iOS users. No `.htaccess` anywhere (besides `/usr/share/debian-reference/.htaccess` which just reads "`AddCharset UTF-8 .txt`"). Nothing noteworthy appearing in Apache's access log, other than that the iPad's Safari apparently registers as an Intel Mac? (`GET ... "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.2 Safari/605.1.15"`) Nothing appears in Apache error log. – sh37211 Aug 28 '23 at 23:09
  • _"Also adding some explicit header language like header("Content-Type: text/html; charset=UTF-8"); to the PHP doesn't help."_ - your problem is that the PHP code was not executed at all - so how is adding one more line of non-executing PHP code supposed to fix this ...? _"Thus, is it Apple-related somehow?"_ - a client can not decide on its own, "I am going to make the server not parse the PHP code, but show it to me raw" - if that was the case, you would've just found the "ultimate hacking tool" in a simple iOS device, because then no include files with stored credentials etc. would be safe. – CBroe Aug 29 '23 at 06:36
  • So _something_ about the requests made by those devices, must be significantly different from what other devices send, to make your server decide to react differently. I'd start by checking the configuration, regarding how exactly PHP is integrated into the web server - and at which point it might depend on certain request characteristics, such as the User-Agent, etc. – CBroe Aug 29 '23 at 06:36
  • In the process of trying to reconfigure things server-side, I first managed to break PHP execution as viewed from *all* machines & browsers. Then, after fiddling with various .conf files, I noticed that PHP was working again, including on the few Apple devices that were having problems. So, I'm not sure what the problem was originally due to, or specifically what I did that finally fixed it. But it *was* fixable *server-side only* and didn't require Apple users to do anything different. (Mods: Due what you will with this post. I understand this answer may not help many others.) – sh37211 Aug 29 '23 at 19:53

0 Answers0