Opened 10 years ago

Closed 10 years ago

#221 closed bug (wontfix)

Weird F5 (page refresh) needed after switch to new server

Reported by: jeanyves Owned by:
Priority: minor Milestone: 0.1.4
Component: BW General Keywords: FR page refresh archive
Cc:

Description

I don't now the reason, but I think we should find a way to avoid this (it is some cahce problem with firefox)

the question is how to force cache to refresh the firstime a member logs on new version ?

Change History (9)

comment:1 in reply to: ↑ description Changed 10 years ago by jeanyves

Replying to jeanyves:

I don't now the reason, but I think we should find a way to avoid this (it is some cache problem with firefox)

the question is how to force cache to refresh the firstime a member logs on new version ?

I have added a short notice in the news of the web site. It will be removed in one week (in the meanwhile, client cache will probably be obsolete/invalid)

comment:2 Changed 10 years ago by micha

I don't know if there is any way to avoid this. I haven't hear of a programmable solution to this. If a website is cached, you have to reload it manually. No way around this.

comment:3 Changed 10 years ago by steinwinde

For the record (and in case of similiar situation in the future):

In HTML / our job:

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

In HTTP / Job of sysadmins:

Expires: Thu, 01 Jan 1900 00:00:01 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

Also we could make sure, that all the content of the page got a recent timestamp. By the way - our server settings seem pretty okay.

comment:4 Changed 10 years ago by jeanyves

Thanks Felix, I think this is exactly what we need.

Do you think it could be possible (some day, not now) to manage "<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">" as an option when we have an update.

This to have all members who log for the first time after the update to use the "<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">" instead of teh classical one, and then back to teh classical one after this first log ?

comment:5 Changed 10 years ago by steinwinde

No, that's impossible: If I'm not completely mistaken, the browser wouldn't even send a request for the new document, if the old, cached one doesn't indicate, that it can't be cached. The META tag has to be read by the browser, *before* we do our update.

Side note: My list of HTML META tags responsible for caching is incomplete.

Anyway, we definitely should introduce an HTML header include for being able to swiftly replace headers globally.

comment:6 Changed 10 years ago by micha

  • Milestone changed from 0.1.1-outreach-bugfixing to 0.1.2 - more improvements & bugfixing
  • Priority changed from major to minor

Our pages still lack the above meta-tags. But anyway I don't think it's a good idea to prevent the user's browser to cache our pages in general. If this would be the result then we would have another speed problem I guess. In my opinion we have to live with F5. Any different opinions here?

comment:7 Changed 10 years ago by philipp

should be possible to automate the refresh by javascript or some other browser hack?

comment:8 Changed 10 years ago by philipp

  • Component changed from BV Forum to BW General

comment:9 Changed 10 years ago by philipp

  • freq_reported set to 1
  • Keywords archive added
  • Resolution set to wontfix
  • show_on_bw set to 0
  • Status changed from new to closed

added "archive" keyword so we can easily look it up later again, closing

Note: See TracTickets for help on using tickets.