#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

[Campbell Morrison]

I think it's a caching issue with the version of js/report.js.php. Can you try running the attached version and see if it fixes the problem?

[Campbell Morrison]

I think it's the same sort of problem that was being seen with Search in Support Request 1142.

[Alex Haines]

Yes that does sound familiar - I'm just going to check the same things you asked GedM to check and report back.

[Alex Haines]

That fixes it - very quick response - awesome!

[Campbell Morrison]

Good, glad it's fixed. What I haven't been able to work out is why your system is ignoring the cache instructions on that file. You're going to see a similar problem with Search and also Edit_users (if you use the 'db' authentication scheme), and so you will need these two files as well.

[Alex Haines]

Thanks. Is there anything I can do to try and help at all?

EDIT: The site is fully SSL / HTTPS if that helps spot differences?

[Campbell Morrison]

Yes, one thing that would be very useful to know is if you are seeing the same symptoms that we were seeing in 1142 when you use the unmodified version of report.js.php. What does the Cache Expiry date look like in the Response Headers? In 1142 we were seeing something like

Wed, 22 Feb 2017 13:31:24 GMT, Wed, 15 Feb 2017 13:31:24 GMT

instead of

Wed, 15 Feb 2017 13:31:24 GMT

[Campbell Morrison]

One other to check if you get a chance please. Do you have any mod_expires directives in your site's .htaccess file? For example

ExpiresDefault "access plus 1 month"

It looks to me as though something on the server is inserting Cache-Control and Expires headers. Although mod_expires seems to say that if there are existing Expires headers it won't modify them, it may be that something is going wrong somewhere (possibly because MRBS is issuing its headers in the wrong way and these are actually being appended to the headers issued by the server).

Another test would be to add the following line to the .htaccess file in the MRBS directory:

ExpiresActive Off

and then see if you get the problem using the unmodified version of report.js.php.

[Alex Haines]

The .htaccess was pretty simple and just redirected all non ssl traffic to HTTPS along with www to non www.

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

# MRBS Testing for Cache Issues
ExpiresActive Off

# SEO URL Settings
RewriteEngine On

# Logging - normally disabled
#LogLevel info rewrite:info

# Redirect www traffic to non www
RewriteCond "%{HTTP_HOST}" "^www\.(.+)$" [NC]
RewriteRule "^(.*)$" "https://%1/$1" [R=301,L]

# Redirect all traffic to HTTPS
RewriteCond "%{HTTPS}" "!=on"
RewriteRule "^" "https://%{HTTP_HOST}%{REQUEST_URI}" [R=301,L]

With the modded .htaccess and the original report.js.php files I now get expected results:

HTTP/1.1 200 OK
Content-Type: application/x-javascript
Expires: Mon, 27 Feb 2017 22:04:20 GMT
Pragma: cache
Cache-Control: max-age=0
Content-Length: 1728
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Mon, 27 Feb 2017 22:04:20 GMT
Accept-Ranges: bytes
X-Varnish: 17971372
Age: 0
X-Cache: MISS
Connection: keep-alive

[Alex Haines]

Assuming within Chrome Developer Tools you meant in Network -> report.js.php -> Response Headers then as follows (otherwise let me know where to look):

Without the modded file:

HTTP/1.1 200 OK
Cache-Control: public, max-age=604800, max-age=0
Expires: Mon, 06 Mar 2017 21:55:32 GMT
Content-Type: application/x-javascript
Expires: Mon, 27 Feb 2017 21:55:32 GMT
Pragma: cache
Content-Length: 1727
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Mon, 27 Feb 2017 21:55:32 GMT
Accept-Ranges: bytes
X-Varnish: 19340255
Age: 0
X-Cache: MISS
Connection: keep-alive

With the modded file:

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Content-Type: application/x-javascript
Pragma: no-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Content-Length: 1727
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Mon, 27 Feb 2017 21:58:41 GMT
Accept-Ranges: bytes
X-Varnish: 19858906
Age: 0
X-Cache: MISS
Connection: keep-alive

Looks like the Expires is duplicated in the unmodded file and then with the modded file it is correctly set it the past.

[John Beranek]

What leaps out to be are the "Varnish" headers - your MRBS pages are being served through a Varnish reverse proxy/caching layer, which could undoubtably change expiry behaviour...

[John Beranek]

I've tried mod_expires on my own vanilla Apache 2.4 configuration, and it works appropriately and only applies Expires headers on URLs which had no Expires header already.

[Campbell Morrison]

From the test results above it looks like adding

ExpiresActive Off

to the .htaccess file solves the problem? In which case is this not the fix for MRBS? That is to add it to the .htaccess file in the MRBS directory?

Looking at 1142's headers (I still have a login) there's no Varnish, though I do see that the server is LiteSpeed.

[John Beranek]

I set:

ExpiresActive on
ExpiresDefault "access plus 1 month"

and for the Ajax search page mrbs/search.php?search_str=another&day=27&month=2&year=2017&area=10&room=19&datatable=1&ajax=1 I get:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Length:261
Content-Type:application/json
Date:Mon, 27 Feb 2017 22:22:49 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=15, max=98
Pragma:no-cache
Server:Apache/2.4.23 (Linux/SUSE)

Whereas for a bit of static content (mrbs/jquery/ui/jquery-ui.min.js), I get the expected Expires header:

Accept-Ranges:bytes
Cache-Control:max-age=2592000
Connection:Keep-Alive
Content-Length:140082
Content-Type:application/javascript
Date:Mon, 27 Feb 2017 22:05:09 GMT
ETag:"22332-5221693367d80"
Expires:Wed, 29 Mar 2017 22:05:09 GMT
Keep-Alive:timeout=15, max=100
Last-Modified:Wed, 14 Oct 2015 20:40:38 GMT
Server:Apache/2.4.23 (Linux/SUSE)

[Campbell Morrison]

Yes, but although mod_expires is working correctly on your system, it seems that whatever's happening on Alex's system is cured by turning off ExpiresActive, if I understand it correctly ("With the modded .htaccess and the original report.js.php files I now get expected results:").

[Alex Haines]

Yes that is what I meant.

[John Beranek]

Mmm, I wonder if there are particular Apache versions/configurations where mod_expires doesn't work properly for PHP pages defining their own Expires headers.

[Campbell Morrison]

Maybe. It'll be interesting to see if turning off ExpiresActive also cure's 1142's problem. I'll send a DM.

[Campbell Morrison]

Another belt and braces fix could be to add the line

header("Pragma: no-cache"); 

to expires_header() if $seconds <= 0?

[John Beranek]

Interesting, in that the MRBS code for seach.js.php is sending:

Pragma: cache

but my Chrome Dev Tools are showing:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Length:261
Content-Type:application/json
Date:Mon, 27 Feb 2017 22:22:49 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=15, max=98
Pragma:no-cache
Server:Apache/2.4.23 (Linux/SUSE)

Where does the "no-cache" come from, and where does the 1981 date come from!?

[Campbell Morrison]

Where does the "no-cache" come from, and where does the 1981 date come from!?

See http://stackoverflow.com/questions/8194481/why-is-expires-1981

[Campbell Morrison]

I think what you are seeing are the headers on the Ajax response, which comes from report.php. What I get there are:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:close
Content-Type:application/json
Date:Tue, 28 Feb 2017 07:59:14 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:Apache
Transfer-Encoding:chunked
Vary:User-Agent
X-Powered-By:PHP/5.4.45

As far as I can see the Ajax response is sent without any cache instructions (maybe it should be?). However for report.js.php, I get what I'd expect:

Cache-Control:max-age=0
Connection:close
Content-Encoding:gzip
Content-Length:670
Content-Type:application/x-javascript
Date:Tue, 28 Feb 2017 07:56:11 GMT
Expires:Tue, 28 Feb 2017 7:56:11 GMT
Pragma:cache
Server:Apache
Vary:User-Agent,Accept-Encoding
X-Powered-By:PHP/5.4.45

[GedM]

Hi guys,
sorry I have not had a chance to test the vanilla install but I will definately do it tomorrow and get back to you ASAP. I thought it was interesting that the two expire dates in the headers in this bug were 7 days apart.
Expires: Mon, 06 Mar 2017 21:55:32 GMT
Expires: Mon, 27 Feb 2017 21:55:32 GMT

This was the same issue in my headers.

If the vanilla install displays the same behaviour, I will try the htaccess changes you have suggested.

regards

[GedM]

Hi,
I set ExpiresActive Off in the htaccess file and restored the original search.js.php file. The duplicated expires header problem no longer exists.

The duplicated header used to appear on all the .js.php files. They all look correct now.

Thanks

[Campbell Morrison]

Great - many thanks. Just to be clear - which .htaccess file was that in? Was it in the .htaccess that ships with MRBS and lives in the MRBS directory together with the config file etc.?