1473708 - Firefox caches PHP output instead of honoring Ctrl+F5

Status: RESOLVED INVALID

(Core :: Networking: Cache, defect)

Description

[David Spector]

Attachment: log.txt-main.9476

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180621125625

Steps to reproduce:

I was asked to post this in response to my posting in Bug 183470. I set up HTTP Logging as described in https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging .

1. I browsed to Web page 'http://localhost/CacheTestCase.php' on my local computer.

2. I enabled logging.

3. I commented out the definition of a PHP constant in file my test file 'CacheTestCase.php'.

4. I pressed Ctrl+F5. The correct response occurred.

5. I restored the definition of the constant.

6. I pressed Ctrl+F5. No response occurred. By that I mean that the page still said, "Constant is undefined." in spite of pressing Ctrl+F5 several additional times.


Actual results:

These results show that in response to my pressing Ctrl+F5 Firefox did not force a reload (including execution of the PHP interpreter) as I expected,


Expected results:

 Ctrl+F5 Firefox should force a reload (including execution of the PHP interpreter) regardless of Apache directives or other environmental settings.

Further information:

1. This bug is similar to several others, including 183470 and 501718.
2. I use the "PHP as a module" not any of the CGI integration methods, as follows:

LoadFile "C:/WAMP/php/libpq.dll"
LoadModule php7_module "C:/WAMP/php/php7apache2_4.dll"

3. In my opinion, this bug reflects a fundamental failure to follow standards, and leads to stale output being displayed in spite of the use of Ctrl+F5, which is documented as forcing the page to be reloaded.

There is nothing wrong with using a cache for true GET data, which does not change for a given Query argument. But in real life, such as with PHP pages, GET is frequently used for freshly-calculated pages instead of POST for convenience.

4. My environment:
Windows 10, Apache/2.4.33 (Win32), PHP/7.0.30, Firefox 61.0 (64 bit)

5. Log file is attached. No child log files were generated.

Comment 1

[David Spector]

Here is the test case that I used:

<?php
// C:\Web\CacheTestCase.php
// localhost/CacheTestCase.php

// Comment out the following line to generate different output:
define("HI","hi"); // Constant
echo F("HI");

function F($Const)
	{
	if (!defined($Const))
		return "Constant is undefined.";
	return constant($Const);
	} // F

?>

Comment 2

[Boris Zbarsky [:bzbarsky]]

Honza, could you take a look please?

Comment 3

[Honza Bambas (:mayhemer)]

Thanks for the very narrowed down log.  I can see 3 request to http://localhost/CacheTestCase.php.  All are going to the server and getting 200 responses:


  HTTP/1.1 200 OK
  Date: Thu, 05 Jul 2018 20:02:40 GMT
  Server: Apache
  X-Frame-Options: SAMEORIGIN
  X-Powered-By: PHP/7.0.30
  Cache-Control: no-store, no-cache, must-revalidate
  Expires: Sun, 10 Feb 2002 16:00:00 GMT
  Pragma: no-cache
  Content-Length: 22
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=UTF-8


  HTTP/1.1 200 OK
  Date: Thu, 05 Jul 2018 20:02:59 GMT
  Server: Apache
  X-Frame-Options: SAMEORIGIN
  X-Powered-By: PHP/7.0.30
  Cache-Control: no-store, no-cache, must-revalidate
  Expires: Sun, 10 Feb 2002 16:00:00 GMT
  Pragma: no-cache
  Content-Length: 22
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=UTF-8


  HTTP/1.1 200 OK
  Date: Thu, 05 Jul 2018 20:03:09 GMT
  Server: Apache
  X-Frame-Options: SAMEORIGIN
  X-Powered-By: PHP/7.0.30
  Cache-Control: no-store, no-cache, must-revalidate
  Expires: Sun, 10 Feb 2002 16:00:00 GMT
  Pragma: no-cache
  Content-Length: 22
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=UTF-8


Hence, this is the PHP engine issue that is probably using a cached result of the compiled script internally or simply fails to detect the change.  I'm not a PHP expert, but I believe you can google for this issue and find something.

I don't see anything wrong with Firefox here.

Comment 4

[David Spector]

Boris Zbarsky, Thank you for recommending that I post this bug report.

As you can see, Honza Bambas has closed the report. I do not understand his explanation. How do the log entries that he quotes prove that Firefox is not returning a page from its cache? Is a log entry made when the cache is referenced?

I do not believe that PHP itself, or Apache on behalf of PHP, maintain any cache of the PHP output. That would be contrary to their scope.

I am at a loss to know how to proceed. Of course I have searched the Web for this problem, but perhaps have used the wrong search terms.

This is a serious problem and has been confirmed. It feels to me like the Firefox team has not investigated it very well.

Even if this is a bug in PHP, I could use some help in pinning it down so I can feel justified in submitting a bug report to the PHP team.

Comment 5

[Honza Bambas (:mayhemer)]

I don't know how else I should explain that there are very clearly 3 requests made to the server in the log for the 3 channels present in the log, getting different responses (at least a different Date response header).  I was really looking reasonably carefully at the log.

David, I'm not a deep PHP expert, but maybe there is a possibility to do more logging in PHP and get some answers on the server side, maybe just add manual logging to your PHP script.

Our logs don't write response content, only response headers.  Maybe if you modify your PHP script to also add a custom response header, we may see that the problem actually happens on the server.

Comment 6

[David Spector]

Honza, thank you for your clarifications.

I examined my Apache server configuration carefully and found no caching enabled.

However, when I examined my PHP configuration carefully, I found that caching was enabled. I found this very surprising, since (especially during development work) one wants PHP to actually run and generate its output! Of course, when PHP files are served in production use, they are not usually changing, so caching makes good sense.

I should have clarified in this bug report that I encountered this problem while doing development work.

Anyway, there are two caching methods enabled by default in the PHP ini file: SOAP (whatever that means) and OPCODE (whatever that means).

When I disabled them, the bug stopped happening. I guess this problem is a PHP bug in which the date-time-modified property of the PHP file is not properly being used to skip caching.

Here is the enabling code, I believe:

[opcache]
zend_extension=php_opcache.dll
; Determines if Zend OPCache is enabled
opcache.enable=1

So, I agree that this is not a bug in Firefox. If you wish to delete this bug report, that would be fine. Or you can leave it to inform others that there may be a problem with PHP opcode caching.

Note that, with opcache.enable=0, F5 is sufficient to see the refreshed output (since Firefox is not doing its own caching, probably in response to all those anti-caching directives in the Apache configuration file).

Comment 7

[Honza Bambas (:mayhemer)]

Bugs can't be deleted.  It's fine to leave it with this resolution for reference.  Thanks for investigating this on your side!

Comment 8

[Boris Zbarsky [:bzbarsky]]

David, thank you for following up on this!

To answer your question from comment 4, the log I asked you to upload records all attempts to do HTTP requests, their URLs, GET vs POST vs DELETE method, whether the requests are serviced from the cache or the network, various information about the connection setup, and the request and response headers.  So a log can be used to determine whether a response came from the cache or from the server.