bkad / prat

group chat with markdown served over websockets
11 stars 6 forks source link

Stale messages #91

Closed bkad closed 11 years ago

bkad commented 11 years ago

Messages received on refresh are stale and don't reflect the current state of the world.

To reproduce:

  1. Send a new message.
  2. On the same page, navigate away (to google.com or something).
  3. Hit the "Back" button on the browser. Note the stale message view.
  4. Hit "Refresh" on the browser. Note the stale message view.
  5. One more refresh should bring and updated view.

It's possible the right cache control headers could fix this... https://code.google.com/p/chromium/issues/detail?id=28035

bkad commented 11 years ago

Some interesting behaviors I've noticed:

1.) On navigating away there's a web socket request. Not sure what it's for. 2.) On coming Back, the only request issued to the server is GET /. The websocket is open however, not sure what's going on here. 3.) On refreshing once, there is a request for the page, all the static assets, and the websocket, but there is no request for all the API requests that happen on load (user statuses, fetching messages). Even though the API requests aren't made, user statuses and message views are populated from the state of the page on a previous load. 4.) On refreshing again, every single request is made.

bkad commented 11 years ago

I threw the Cache-Control textbook at it and slowly whittled it away until it stopped working.

I started with:

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache

and ended with:

HTTP/1.1 200 OK
Cache-Control: no-store

I'll push it out and see what happens.

bkad commented 11 years ago

298e03646b8716a46b677cbca758180986d786ec fixes it for chrome/OSX

bkad commented 11 years ago

also fixed in chrome/ubuntu

still broken in chrome/windows

trying to gauge how many shits i can still give