Major cache, cookie or session issue after upgrade to 5.1.5

[DisasterDotCom]

Thanks ozzy. Yeah - I'm considering that, but I'm not certain how I can import new threads from the past four days into a restore. We didn't hear about this until 3 days after the upgrade occurred, but we did verify that it was happening almost immediately after. I don't want to lose the updates (we're a disaster and crisis forum, and there are numerous discussions in our "active disasters" forums about what's going on in the world right now). But.. if I can't figure this out today, I'll go back no matter what.

[ozzy47]

Yeah, it kinda sucks, but that may be your best option at this point in time, better off go loose a couple of days, rather than loosing members cause of the issues.

Hopefully though, vB support come with a breakthrough today though.

[DisasterDotCom]

When a page has been updated, shouldn't vBulletin be resetting the Date: in the HTTP header?

Here's what I'm seeing... I make the original post at 15:12:05 UTC. I make a reply immediately after at 15:12:10 UTC. The page still shows the Date: as 15:12:05 UTC. I leave the page and go to the main forum page, then return to the post. It STILL shows the Date: as 15:12:05 UTC until I refresh it. So.. the client isn't being told there's an update to the page. This is set by vBulletin, isn't it? Since the pages are create dynamically?

This is through header inspection in the network tab of Chrome developer tools.

[Paul M]

Originally Posted by DisasterDotCom

The response from support (after 24 hours) was "Clear your system cache and local browser cache". This was the first thing we tried before we even opened up tickets

Did you tell support you did that before they replied ?
They dont have special magic powers to know what you have or have not done.

Originally Posted by DisasterDotCom

These issues all seem to be related to a caching or cookie issue, or maybe a session issue somewhere. They are causing MASSIVE usability issues across our forums. Please help!

Those are not cookie issues, they look like cache issues, possibly within vB, but hard to tell.

Turn off the vB Cache system for a while (its in options, not sure where, I cannot look it up from here).

[DisasterDotCom]

No - I'm not complaining that the first thing they told me was to clear the caches. What is a bit upsetting is that I replied to the request within 15 seconds and they have not replied back yet (since yesterday) except on the vbulletin.com board. But, right now, I care more about solving these problems than complaining about poor support response times.

In between testing I'm enabling the "no-cache" function ("Add No-Cache HTTP Headers").

I do appreciate your responses.

--------------- Added [DATE]1423067894[/DATE] at [TIME]1423067894[/TIME] ---------------

So just to update... I turned debug on in the config file and looked at time stamps (generated BY vbulletin at the bottom of each rendered page):

Initial Post - Current Time: Wed, 04 Feb 2015 11:31:39 -0500
After Comment - Current Time: Wed, 04 Feb 2015 11:31:39 -0500
Click on forum link - Current Time: Wed, 04 Feb 2015 11:31:03 -0500
Hit refresh - Current Time: Wed, 04 Feb 2015 11:33:12 -0500
Click on topic again - Current Time: Wed, 04 Feb 2015 11:31:39 -0500
Click refresh - Current Time: Wed, 04 Feb 2015 11:35:15 -0500

Note that when I click on the forum link I go back in time (even though I've made a new post). I refresh, we come back to the current time.

Then when I click on the topic again, the time stamp matches the initial post time - NOT the time after I made the comment. Once again, I refresh and we come back to the current time and the reply shows.

[Zachery]

vBulletin has two choices for cache headers: NONE, zip, zilch, nada, no headers will be sent AT ALL in regards to caching content. That or we EXPLICITLY send a no cache header. Those are the ONLY two options with the software. If ANY other cache headers are being sent, its coming from the webserver and or its configuration. At least, in regards to the HTML content type, which is the output of all normal vBulletin page(s)

You refreshing (forcing your browser to ignore the cache headers) is doing exactly what it should, forcing a check. The reason the site is "responsive" when cache headers are on, is your browser is just grabing the site from its local cache, instead of waiting for webrequests/responses.

[DisasterDotCom]

Update...

The headers get sent down by vBulletin or Apache, but the only thing that's changed is vBulletin, and this started immediately after the change. It occurs with both Chrome and Firefox.

Looking at the logs:

1. I click on new thread GET /forums/new-content/44 HTTP/1.1
2. I make the post POST /forums/create-content/text/ HTTP/1.1
3. The page refreshes GET /forums/forum/general/test-forum/28305-this-is-another-new-topic
4. I add a reply POST /forums/create-content/text/ HTTP/1.1
5. The reply shows up POST /forums/create-content/loadnode HTTP/1.1
6. I go to the parent forum of the post GET /forums/forum/general/test-forum HTTP/1.1
7. I click on the post, page displays and a POST /forums/ajax/api/node/incrementNodeview HTTP/1.1 and then GET /forums/foru...-another-testt HTTP/1.1

Everything has a status code of 200. Item 6 and 7 have a Cache-Control: max-age=3600 and the date and time of the original post.

Isn't the process from the client to the server supposed to be something like... pull down the original page and cache it locally. Request the same page later, send a request to the server for a header to see if the page has a new time, if they match then pull the local copy, if they don't match send the new copy. Apache has no idea whether the page has been updated or not - that is generated by vBulletin, correct?

--------------- Added [DATE]1423090573[/DATE] at [TIME]1423090573[/TIME] ---------------

Alright... after 8 hours of troubleshooting, and Zachery (on vbulletin.com) mentioning that there are only two types of caching - on or off - I found this is not a vBulletin issue.

For future reference... IF you have vBulletin installed in a subdirectory (i.e. /forums), and the PARENT directory has an .htaccess file, the directives from this parent .htaccess file will be used. Any directives you have in the subdirectory will override those of the parent, but if there's something in the parent that's NOT in the subdirectory .htaccess, it will be pulled from the parent.

In our case, the parent .htaccess had the following directives (in addition to many others):

ExpiresByType text/html A3600
ExpiresByType text/richtext A3600

These were setting a 3600 second (60 minute) expiration on HTML content.

I've modified the vBulletin .htaccess file to be the following:

ExpiresByType text/html A0
ExpiresByType text/richtext A0

This effectively sets max-age to 0 so HTML does not cache.

We're still trying to figure out why this is corresponding to the upgrade to 5.1.5. Something had to change somewhere, because (as far as we know) nothing else changed.

[ozzy47]

Well glad to hear that is sorted. Now you don't have to roll back to the backup.

[Zachery]

We changed some of the facebook code, which was previously always sending headers, and no longer does.

Also, .htaccess / vhost rules always filter into sub-folders.