I'm running the most recent Apple Safari.

When I first get on the SO site I will have reputation notifications like "+5" and click it and it shows the unread stuff that happened while I was away like "+5 rep for up-vote of this question.", if I navigate to another page (for example clicking on that notification to take me to the page I got +rep from) it loads the "viewed" property of that notification, realizes that I've already read it, and does not display it. But then if I click the text in the top left corner of the page (beneath the tool bar) saying "StackOverflow" (to the left of the Questions Tags Users etc. buttons. it takes me to the "home" page but does not re-check the "viewed" property of that notification and it displays a new notification (even though I've already seen it!)

If i restart my "session" by say opening a new tab and going to SO home page URL this does not happen, so it is something that occurs when clicking the "StackOverflow" text to go home.

  • That's because Stack Exchange uses Cache-Control: public, max-age=60 for its HTML pages. So your browser caches the page for 60 seconds, and does not reflect the read status of the notifications.
    – Antony
    Mar 30 '14 at 5:44
  • @Antony not really. The live refresh is not cached. I can't reproduce this behavior. Mar 30 '14 at 8:11
  • @ShadowWizard The live refresh isn't, but the HTML is. And if you click the logo within 60 seconds, it behaves as if it forgets that you have read the notification.
    – Antony
    Mar 30 '14 at 8:12
  • @Antony so can you reproduce this? I tried to click within the 60 seconds and it didn't re-appear. Mar 30 '14 at 8:14
  • @ShadowWizard Step 1: See a new notification in top bar. Step 2: Read the notification. Step 3: Click elsewhere to dismiss. Step 4: Click meta logo to refresh. You can see that the notification reappears even though it shouldn't. This is because the notification comes with the HTML and is cached for 60 seconds.
    – Antony
    Mar 30 '14 at 8:18
  • Note the Vary:* in the headers, @Antony: shouldn't browsers always ask the server if the cache is valid? (My Chrome does so using If-Modified-Since in the request.) Also, I wonder (but could not check right now) if notifications are ever in the HTML source. (When I load the page, I immediately see the socket opening; I always figured it would get any notifications at that point, not in the HTML, but you might be right there.)
    – Arjan
    Mar 30 '14 at 9:11
  • @Arjan What the browsers should do is one thing, what they actually do is another. I know that Safari has a lot of bugs, this could just be another one of them. I just did a $.get(location.href) in the console and verified that the notifications are in the HTML source.
    – Antony
    Mar 30 '14 at 9:16

You're seeing bad behaviour of Safari, which boldly shows cached content while it should revalidate at the server. Next, if initially the HTML already included the counter (rather than the counter being updated using a web socket), like:

<span class="unread-count" style="">1</span>

...then somehow clicking through to any page within 60 seconds after it was initially loaded, will again show the counter value from the cached HTML.

Now, to make things complicated: Safari's Web Inspector claims the content is not fetched from cache. But using Wireshark reveals that within the first 60 seconds it does not make new requests, and in Safari's Web Inspector one then sees that the dates in the response do not change when clicking the logo, despite the label "Cached: no":

That's not the expected behaviour. When logged in, the server responds with either:

Cache-Control: public, max-age=60   
Expires: Sun, 30 Mar 2014 18:55:51 GMT  
Last-Modified: Sun, 30 Mar 2014 18:54:51 GMT    
Vary: *
Date: Sun, 30 Mar 2014 18:54:51 GMT


Cache-Control public, no-cache="Set-Cookie", max-age=60
Set-Cookie: ... expires=Tue, 30-Sep-2014 18:54:51 GMT; path=/; HttpOnly
Expires: Sun, 30 Mar 2014 18:55:51 GMT  
Last-Modified: Sun, 30 Mar 2014 18:54:51 GMT    
Vary: *
Date: Sun, 30 Mar 2014 18:54:51 GMT

Note the Vary: * header above, for which the specifications say:

When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.
A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.

In Safari, within the 60 seconds that the cache is valid, clicking the logo will make Web Inspector show it makes a new request for the page without any restrictions. (Again: Wireshark reveals that no such request is made at all, so that information is false.) Only when waiting a full minute after the last request, clicking the logo will make Safari truly send a new request, with an additional conditional request header:

If-Modified-Since: Sun, 30 Mar 2014 18:54:51 GMT

Chrome and Firefox always make a real request. Chrome then always includes If-Modified-Since, while Firefox never sends that. Even with that header, when logged-in, the Stack Exchange server always seems to return a new page and never returns 304 Not Modified, not even on low-traffic sites such as Meta.

When not logged-in, 304 is used. And one sees that some server-side cache is doing some countdown, where the number 60 counts down to zero:

Cache-Control: public, max-age=34

This first made me think that Safari somehow got some cached server response while logged-in as well, until Wireshark showed me Safari's Web Inspector was showing fake details.

  • 2
    (Reported to Apple as #16468795.)
    – Arjan
    Mar 30 '14 at 22:00
  • Thankyou :) I'll keep my eyes peeled for a Safari update :D Mar 31 '14 at 1:23
  • I don't know much about this stuff but I did some research and thought I'd pass this your way, is this the same thing we are dealing with or am I off base? (Again I know barely any "HTML webkit javascript etc." stuff) mrclay.org/2009/02/24/… Mar 31 '14 at 1:27
  • 1
    Sounds like that is exactly the opposite, @Albert That browser cannot make up its mind, it seems ;-) (The good news is: that current bug might then not be over 5 years old!)
    – Arjan
    Mar 31 '14 at 15:20
  • That is good news indeed :) Mar 31 '14 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .