#1142 Same Search results returned on sebsequent searches

[Anonymous]

When a search is conducted the first search returns correct results but subsequent searches returns the same results as the first search even when a different search term is used. It seems our browser or server is caching the ajax page which is returning the results. Is there a way around this?

[John Beranek]

Just to check, which search do you mean? If you mean the search panel just above the table on the search results page (search.php), then this doesn't perform a new search, it searches within the search results.

[John Beranek]

As for caching of the search results, MRBS tries very hard to make sure nothing caches the page:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Type:text/html; charset=utf-8
Date:Wed, 15 Feb 2017 09:18:58 GMT
Expires:Mon, 26 Jul 1997 05:00:00 GMT
Keep-Alive:timeout=15, max=100
Pragma:no-cache

[Campbell Morrison]

I've just done a quick test and can't reproduce this (if you meant caching of the search results). I did a search in one browser, created a new event in another and then repeated the search in the first browser. The new event showed up as expected.

[Anonymous]

Hi John and Campbell,
Thank you for the quick response.

I am refering to the search box at the top of the page. The advance search is also only showing the results from the first search conducted. For example, if I search for the word 'test' I get a result. If I then click back and search for 'search' the results for 'test' are shown but the text at the top left of the page updates correctly with 'Search Results for: "search"'.

As I do this test now, the results being shown are from 11 hours ago.

I will message you the webiste address and login details so you have have a look see.

Thanks

[Campbell Morrison]

Thanks for the login details. Yes, I can now reproduce the problem on your system. Strange! I'll have a think about it.

[Campbell Morrison]

I can see that the search string sent in the Ajax request is still the old search string. I'll see if I can figure out why.

[Campbell Morrison]

OK - I think I see what the problem is, and I'm working on a fix (and trying to figure out why I'm not able to reproduce it on my system).

[Campbell Morrison]

I think the problem is to do with the use HTTP_REFERER in js/search.js.php, but I haven't yet figured out why it works on my system and not yours.

[Campbell Morrison]

Could you try this version of js/search.js.php and see if it makes any difference?

[Campbell Morrison]

I can see from Chrome developer tools that when I'm using your server the search.js.php file is coming from disk cache, while when I'm using my server it's being downloaded afresh from the network. I'm not quite sure why that is and both servers are using HTTP 1.1, but what I've done in the file above is changed the cache control headers to see if it makes any difference. You'll obviously need to flush the browser cache first. (As the file contains the search string this would explain what's happening. It's probably not a very good idea to have the search string in the file anyway, so in the longer term I'll think about a different way of doing things.)

[Campbell Morrison]

I can also see that the Cache Expiry date in the Response Headers on your system looks like this

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

whereas I would expect

Wed, 15 Feb 2017 13:31:24 GMT

Have you modified functions.inc at all? In particular rfc1123_date() or expires_header()?

[GedM]

Hi Campbell,
I have made some changes to functions.inc but I did not change either of those functions.
I'll do a compare with a fresh install and see what I've done.

Your new search.js.php has fixed the problem.

I use Firefox and Firebug and can see the odd Cache Expirey date in the .js.php responses but the normal .php responses don't display that issue. Also, the expiry date of the normal php responses is one week from today. As I am the only one who has experienced this issue, it looks like this is something I have done. Please done spend anymore time on this. I'll look into is more closely and get back to you soon with my findings.

Thanks for your assistance.

[GedM]

Hi Campbell,
I don't know if this is any help but the version of 1.5.0 my server is based on was downloaded from HG web on 30 Sep 2016. The downloaded file was called mrbs-hg-code-12cda8ce787e89d9003e4c4e29b3281eb1f15d69.zip

I've checked my changes against the downloaded files and I haven't changed anything which may have affecetd the headers or the date format.

I will download ver 1.6.0 and make my edits against that version. If the Expired dates are changed after my edit I will know it was me.

Thanks.

[GedM]

BTW The two functions you asked about are:

// Format a timestamp in RFC 1123 format, for HTTP headers
//
// e.g. Wed, 28 Jul 2010 12:43:58 GMT
function rfc1123_date($timestamp)
{
  return gmdate("D, d M Y G:i:s \\G\\M\\T",$timestamp);
}

// A little helper function to send an "Expires" header. Just one
// parameter, the number of seconds in the future to set the expiry
// (We also send a couple of extra headers as the "Expires" header alone
// does not always result in caching.)
function expires_header($seconds)
{
  header("Expires: ".rfc1123_date(time()+$seconds));
  header("Pragma: cache");
  header("Cache-Control: max-age=$seconds");
}

[Campbell Morrison]

Yes, those two functions look fine. I'm keen to get to the bottom of this in case there's something about your webserver set up that is exposing a bug in MRBS.

Let us know if a vanilla install of MRBS 1.6.0 works properly. If it doesn't then there's a problem we need to investigate.

[Campbell Morrison]

Did you ever try a vanilla install of 1.6.0? It looks like someone else is seeing a similar problem with Report in Bug 379.

[Campbell Morrison]

See also my comments and questions about mod_expires in Bug 379.