11

Seems like onClick actions in general are mostly broken on question pages. I can perform all actions on MSO. Can't upvote on SO, DIY, or programmers. Cannot "show more comments", open inbox, see user "cards", favorite a question, add a comment, or upvote/delete comments as well.

Running Firefox 9.0.1.

Have tried:

  • refresh
  • ctrl-r
  • clearing browser cache
  • restarting browser
  • Tried logging out, can't figure out how to do that without the JS dropdown :)
18
  • Have you tried refreshing your cache? There has been a change to the jQuery served by the site. See - meta.stackexchange.com/a/115428/59303
    – ChrisF Mod
    Jan 3, 2012 at 13:01
  • Perhaps related: I am having problems deleting a comment from this question using firefox. I already hit F5 and <cntl>-r to refresh jQuery, but no success so far. Jan 3, 2012 at 13:05
  • 1
    I'm having the same problem starting today; last week, it was OK. I'm using Chrome (build 16.0.912.63). Steve, I cleared my cache and all saved passwords so it would force a login; this didn't help. Jan 3, 2012 at 13:16
  • @Scrooge I can add this comment here on Meta, but I can't add comments or open my "inbox" or anything on Stackoverflow. I get a "StackExchange is not defined" JavaScript error. (Yes I've cleared my cache.)
    – Pointy
    Jan 3, 2012 at 13:19
  • 1
    Can't repeat with SO using FireFox (7.0.1, 8.0.1, 9.0.1) or IE 9. Hrm. Jan 3, 2012 at 13:47
  • 2
    What does cdn.sstatic.net/js/stub.js?v=db457559e6b0 give you?
    – balpha Staff
    Jan 3, 2012 at 13:50
  • 1
    @balpha, I get 406 - Client browser does not accept the MIME type of the requested page. The page you are looking for cannot be opened by your browser because it has a file name extension that your browser does not accept. (FF 8.0 on Ubuntu 11.10) Jan 3, 2012 at 13:52
  • 3
    @balpha "406 - Client browser does not accept the MIME type of the requested page. The page you are looking for cannot be opened by your browser because it has a file name extension that your browser does not accept." Jan 3, 2012 at 13:52
  • Norepro, same Firefox version on Windows.
    – a cat
    Jan 3, 2012 at 13:54
  • @balpha, same results with Chrome on Ubuntu 11.10 - 406 - Client browser does not accept the MIME type of the requested page. The page you are looking for cannot be opened by your browser because it has a file name extension that your browser does not accept. Jan 3, 2012 at 13:54
  • I have the same problem on Windows with FF 5 (and now also with 9), Chrome 15, and IE 9. Also get the 406 error when hitting the link provided by balpha.
    – M.Babcock
    Jan 3, 2012 at 14:00
  • Try now (cc @MikePennington)
    – balpha Staff
    Jan 3, 2012 at 14:00
  • @balpha - Works for me now.
    – M.Babcock
    Jan 3, 2012 at 14:01
  • @balpha, now I'm getting javascript in both FF and Chrome. What changed to break things? Jan 3, 2012 at 14:02
  • @balpha Works for me! Jan 3, 2012 at 14:03

1 Answer 1

20

Interesting issue. Very probably, this is what happened: Some user (with a broken browser, I guess) requested the JavaScript file from the CDN, and this request was a cache miss; in other words, the CDN's edge server didn't have this file at hand. In that case, it requests the file from us, apparently (and this is the important part) forwarding the user's request headers.

So we received the broken browser's headers and responded with "406 You're broken". The CDN's server then cached this response, thus responding to every subsequent request (even non-broken ones) with the same error response.

This is just a theory, but I'd say it's correct with 99.9% probability, in particular since as soon as I purged the CDN cache (and with it the 406 response), all three people reporting this error said "yep, works again."

To confirm that this theory is correct, and also to give the data to our CDN provider (as this is obviously something that shouldn't happen again), please let me know what CDN data center you're hitting: http://debug-02.netdna-cdn.com/ will give you that information.

If my theory is correct, the three of you will probably be hitting the same data center (the probability that this issue would happen on two different servers simultaneously is pretty low).

Follow-up: It turns out that this was in fact our fault, not the CDN's. With every response to a static file request, we were returning a Cache-Control: max-age=604800 header, in other words, we were saying that the response is cacheable for a week; we were doing this for every response, regardless of the status code. The applicable RFC is pretty clear about this situation (emphasis mine):

A response received with any [status code other than 200, 203, 206, 300, 301 or 410] MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a "max-age", "s-maxage", "must- revalidate", "proxy-revalidate", "public" or "private" cache-control directive (section 14.9).

This means that the CDN was just following the standard by caching and reusing this response (there was no Vary header on the response); any other caching proxy between us and the user could have done the same thing.

It looks like it's not possible to solve this problem in general with IIS. Thus we're probably going to solve this issue by having our load balancer (HAProxy) strip the Cache-Control header from any response that does not have the status 200.

8
  • "You are hitting the NetDNA Dallas Datacenter" Jan 3, 2012 at 14:20
  • "You are hitting the NetDNA Dallas Datacenter" Jan 3, 2012 at 14:22
  • Great writeup, +1. If someone can identify what broken request did this, I think it would be valuable... if nothing else, to put in place checks to ensure an intentional DoS of the same type cannot be performed Jan 3, 2012 at 14:22
  • @MikePennington: It's close to impossible to do this intentionally, since you'd have to know that your request is going to be a cache miss. The CDN serves 100-200 requests per second, and almost all are cache hits. Still, this obviously shouldn't happen in the first place.
    – balpha Staff
    Jan 3, 2012 at 14:34
  • "You are hitting the NetDNA Dallas Datacenter" Jan 3, 2012 at 15:04
  • You are hitting the NetDNA Dallas Datacenter Jan 3, 2012 at 15:10
  • Just for a little further confirmation, I was not having the problem, and I get "You are hitting the NetDNA Atlanta Datacenter" Great catch! Jan 3, 2012 at 15:54
  • This was a fun ticket to work on. It's always a pleasure working with you on this Ben, I always learn something awesome.
    – jdorfman
    Jan 9, 2012 at 23:52

You must log in to answer this question.

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