What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 133 Stack Exchange communities.

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 :)
share|improve this question
    
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 Jan 3 '12 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. –  Mike Pennington Jan 3 '12 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. –  Ghost Jan 3 '12 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 '12 at 13:19
1  
Can't repeat with SO using FireFox (7.0.1, 8.0.1, 9.0.1) or IE 9. Hrm. –  jadarnel27 Jan 3 '12 at 13:47
2  
What does cdn.sstatic.net/js/stub.js?v=db457559e6b0 give you? –  balpha Jan 3 '12 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) –  Mike Pennington Jan 3 '12 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." –  Steve Jackson Jan 3 '12 at 13:52
    
Norepro, same Firefox version on Windows. –  lunboks Jan 3 '12 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. –  Mike Pennington Jan 3 '12 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 '12 at 14:00
    
Try now (cc @MikePennington) –  balpha Jan 3 '12 at 14:00
    
@balpha - Works for me now. –  M.Babcock Jan 3 '12 at 14:01
    
@balpha, now I'm getting javascript in both FF and Chrome. What changed to break things? –  Mike Pennington Jan 3 '12 at 14:02
    
@balpha Works for me! –  Steve Jackson Jan 3 '12 at 14:03

1 Answer 1

up vote 19 down vote accepted

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.

share|improve this answer
    
"You are hitting the NetDNA Dallas Datacenter" –  Steve Jackson Jan 3 '12 at 14:20
    
"You are hitting the NetDNA Dallas Datacenter" –  Mike Pennington Jan 3 '12 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 –  Mike Pennington Jan 3 '12 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 Jan 3 '12 at 14:34
    
"You are hitting the NetDNA Dallas Datacenter" –  Ghost Jan 3 '12 at 15:04
    
You are hitting the NetDNA Dallas Datacenter –  Bill Ruppert Jan 3 '12 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! –  jadarnel27 Jan 3 '12 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 '12 at 23:52

You must log in to answer this question.

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