#379 report.php table issue

[Anonymous]

Picture the scenario:

When running a report via report.php and selecting a date range of say 01st Dec 2016 to 31st Dec 2016 and pressing Run Report or the Enter key I receive:

208 entries found
"THE TABLE OUTPUT"
Showing 1 to 25 of 208 entries

So that all looks correct.

I now want to filter the results by using 'Match brief description:'. I use the word 'age' and run the report and I receive:

3 entries found
"THE TABLE OUTPUT"
Showing 1 to 25 of 208 entries

3 entries found is correct but it still outputs the previous table contents with all 208 entries. If I now press Ctrl + F5 to refrsh the page I get the expected results of:

3 entries found
"THE TABLE OUTPUT"
Showing 1 to 3 of 3 entries

Now if I go to report.php and then search via the date range and the word 'age' at the same time I receive:

3 entries found
"THE TABLE OUTPUT"
Showing 1 to 25 of 381 entries

This appears to be all forward dated entries from the report date as of today rather than the selected date range on the form. Again if I Ctrl + F5 this I get the correct result of:

3 entries found
"THE TABLE OUTPUT"
Showing 1 to 3 of 3 entries

Any ideas welcome!?

I did think maybe this was a caching issue but I have disabled all caching that I know of on the server and no difference. I also tried pushing no-cache via HTTP headers but that also didn't help.

System:

Meeting Room Booking System: MRBS 1.6.1
Database: MySQL 10.0.27-MariaDB-cll-lve
System: Linux ing.co.uk 3.10.0-427.36.1.lve1.4.37.el7.x86_64 #1 SMP Sat Feb 4 07:05:07 EST 2017 x86_64
Server Time: Mon 27 Feb 2017 18:36:13 GMT
PHP: 7.1.2

[GedM]

Yes. That was it. The totals contents are:

ExpiresActive Off

<Files ~ "\.inc$">
   Order allow,deny
   Deny from all
</Files>

[Campbell Morrison]

Ok, thanks. Looks like ExpiresActive Off does the trick on both sites. Obviously no need to try a vanilla install now. I'm still intrigued as to why we've had a rash (well, two!) of these problems appear in the last week or two, but it looks like we now have a solution.

[GedM]

Do the js.php files go through a different process when generating the headers? These are the only files which have an issue and one of the expires headers is correct, the other is always 7 days in the future.

[Campbell Morrison]

Yes, the headers are generated by the function expires_header($seconds) in functions.inc, as opposed to http_headers() which is used for the php pages that shouldn't be cached. What's happening is that even though we set $seconds to zero for JavaScript files that shouldn't be cached, they are being cached on your systems. As well as modifying the .htaccess file, I'm thinking of also changing the expires_header() function so that if $seconds <= 0 then the Pragma is set to No-cache and the expiry date a date in the past (this is the change I made in the original modded versions of report.js.php and search.js.php).

(What I'm unclear about is why your servers are behaving this way. It looks like we have a fix, but it would be good to know why. It may be that your servers do something dependent on the content type and assume that JavaScript and CSS files can be cached. I might write some test pages to test this theory.)

[Alex Haines]

I've asked a vague question about caching on this particular box and await a response. I might cite them back to the topic so that they can see this question in context.

Let me know what you need me to try etc.

[Campbell Morrison]

Here are four very simple test programs. They each produce headers in the same way that report.js.php does. The only difference between them is the Content-Type header. All they do is produce the headers and then echo their content type.

Could you run each of the four programs and then let me know what the response headers look like in each case? They don't depend on any MRBS files so can be run standalone in any directory - though make sure that ExpiresActive Off hasn't been set for that directory.

[Alex Haines]

test_css.php:

HTTP/1.1 200 OK
Cache-Control: public, max-age=604800, max-age=0
Expires: Tue, 07 Mar 2017 16:14:52 GMT
Content-Type: text/css;charset=UTF-8
Expires: Tue, 28 Feb 2017 16:14:52 GMT
Pragma: cache
Content-Length: 28
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Tue, 28 Feb 2017 16:14:52 GMT
Accept-Ranges: bytes
X-Varnish: 22194530
Age: 0
X-Cache: MISS
Connection: keep-alive

test_html.php:

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Expires: Tue, 28 Feb 2017 16:15:23 GMT
Pragma: cache
Cache-Control: max-age=0
Content-Length: 29
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Tue, 28 Feb 2017 16:15:23 GMT
Accept-Ranges: bytes
X-Varnish: 24642182
Age: 0
X-Cache: MISS
Connection: keep-alive

test_js.php:

HTTP/1.1 200 OK
Cache-Control: public, max-age=604800, max-age=0
Expires: Tue, 07 Mar 2017 16:16:15 GMT
Content-Type: application/x-javascript
Expires: Tue, 28 Feb 2017 16:16:15 GMT
Pragma: cache
Content-Length: 44
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Tue, 28 Feb 2017 16:16:15 GMT
Accept-Ranges: bytes
X-Varnish: 17836569
Age: 0
X-Cache: MISS
Connection: keep-alive

test_json.php:

Accept-Ranges:bytes
Age:0
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:16
Content-Type:application/json
Date:Tue, 28 Feb 2017 16:16:37 GMT
Expires:Tue, 28 Feb 2017 16:16:37 GMT
Pragma:cache
X-Cache:MISS
X-Varnish:14669131

[Campbell Morrison]

Thanks for running those. Interesting results. It looks as though for CSS and JavaScript files something somewhere in the system is saying they can be cached, while for HTML and JSON files it assumes they can't. I suspect it's an ExpiresByType directive somewhere, which is then disabled when you set ExpiresActive to Off.

Even so, if mod_expires is adding the caching headers then I don't think it should be, as the documentation says "When the Expires header is already part of the response generated by the server, for example when generated by a CGI script or proxied from an origin server, this module does not change or add an Expires or Cache-Control header." Anyway, whatever it is, setting ExpiresActive to Off seems to stop it.

[John Beranek]

Of interest is that the Apache 2.0 documentation does not contain the statement about not overriding existing headers:

http://httpd.apache.org/docs/2.0/mod/mod_expires.html

2.2's documentation does have the statement, as per 2.4.

[John Beranek]

Alex/GedM: Could you let us know the version of your Apache server?

[Alex Haines]

I'm going to have to ask the host but a phpinfo(); shows:

Server API  LiteSpeed V6.10
$_SERVER['SERVER_SOFTWARE'] LiteSpeed

[John Beranek]

So, LiteSpeed attempts to be Apache compatible, but I imagine its behaviour differs in a number of areas...

[Alex Haines]

That is going to be my best guess yes. cPanel also reports no Apache and LiteSpeed.

A quick Google showed me the following. It's old but it looks the same on a cursory glance:

https://www.litespeedtech.com/support/forum/threads/settting-expires-cache-control-headers-buggy.5919/

[Campbell Morrison]

I've now updated the code in the default branch by

(a) Adding ExpiresActive Off to the MRBS .htaccess file

(b) Modifying expires_header() so that if $seconds <= 0 it sets a date way in the past and also the no-cache Pragma (just like the standard header does)

(c) Modifying all json and application output (eg .ics, .csv) so that the headers are explicitly set for no caching. (While the PHP session scheme normally does this anyway, other session schemes, eg 'cookie', won't and so now MRBS explicitly sets no caching on this type of output just to make sure).

See 9e1f7e and earlier commits.

[Campbell Morrison]

I've also now changed those three js.php files so that they can be cached. See b900be.

[Campbell Morrison]

I've now removed the "ExpiresActive Off" directive from the .htaccess files in the default branch (see a2bb22), as it is no longer necessary given other changes to the code and could interfere with a site's caching policy. In particular, the change (b) two posts above should ensure that MRBS's dynamic CSS and JavaScript files are not cached. Besides, the change in the post immediately above means that there are no longer any such files.

For those MRBS 1.6.1 sites suffering from this problem, adding the line

ExpiresActive Off

to your MRBS .htaccess file is an easy to apply, temporary, fix until you update to the latest version of the code.