14

I don't know if this is 100% true, but I live in China, and I now require a VPN to access Stack Overflow. It seems like the following files aren't loading in China. The index page itself is loading, but eventually ↓these↓ time out and the Stack Overflow page is presented without CSS.

I have just tested with :

  1. Chinese Beijing Bandwidth (Blocked/Unstable)
  2. Chinese 3G internet (Blocked/Unstable)
  3. Japanese VPN Server (Available)
  4. American VPN Server (Available)
  5. Korea VPN Server (Available)

https://cdn.sstatic.net/js/stub.js?v=13ec16e2d347

https://cdn.sstatic.net/stackoverflow/all.css?v=62fd31659efc

Edit: after some reading and searching. I think it's some sort of URL block for URL cdn.sstatic.net

Edit: It's just Stack Overflow problem. It's not the firewall. They do work with:

http://cdn.sstatic.net/js/stub.js?v=13ec16e2d347

http://cdn.sstatic.net/stackoverflow/all.css?v=62fd31659efc

  • 16
    So because your machine isn't displaying the content from the CDN, it must be affecting all of China? This has affected a lot of people for a variety of reasons - you should look through those to see potential solutions for your individual scenario before sounding the alarms and making people think it is affecting a billion people. – Aaron Bertrand Aug 1 '13 at 3:19
  • 1
    What @AaronBertrand said; while there could seem to be some (backwards) logic in China blocking sstatic.net, it seems much more likely it's a more mundane problem here. – Andrew Barber Aug 1 '13 at 4:38
  • Those URLs are both HTTPS so nobody could be blocking the content based on the domain name. – uɐɯsO uɐɥʇɐN Aug 1 '13 at 5:34
  • 1
    @AaronBertrand You're right, I'm not completely sure, so I probably should not sound the alarm. But I've tested it and it doesn't work in China, but it works when I'm connected to an Japanese VPN. StackOverflow has been blocked very often lately, So I decided to ask Meta to see if anyone else or if the crew has a more complete idea of what's happening. (By the way this is common, China blocks foreign hosted sites randomly, but they block certain important targets often(Google) and some completely (Youtube, Facebook)) – Louis Hong Aug 1 '13 at 5:44
  • 1
    A fun detail is Meta.Stackoverflow.com is working because stub.js and all.css are hosted on: meta.stackoverflow.com/content/js/stub.js?v=13ec16e2d347 meta.stackoverflow.com/content/stackoverflowmeta/… rather then cdn.sstatic.net – Louis Hong Aug 1 '13 at 5:46
  • 1
    @YuHao Dammit, the Golden Shield Project wiki page is blocked to, this is just too "clever". – Louis Hong Aug 1 '13 at 5:58
  • For those who are not familiar with China's notorious Great Fire Wall, check out Golden_Shield Project. By the way, I live in China as well, and it happened to me sometimes. – Yu Hao Aug 1 '13 at 6:00
  • @YuHao Do you think we should encrypt the sensitive keywords in this question so Stackvoverflow domain won't be bl0cked? But then people that don't live in China won't understand why we are doing it... – Louis Hong Aug 1 '13 at 6:06
  • I wonder if DNS services are filtered, @Nathan? If so, then a HOSTS file on your machine might help, Louie. Can you get to debug-02.netdna-cdn.com? And it would be nice if we'd know of some other website that happens to use the exact same CDN, but how to find one? – Arjan Aug 1 '13 at 6:14
  • This is a better wiki page for the G0LDEN PR0JECT, the page is duplicated. en.wikipedia.org/wiki/… – Louis Hong Aug 1 '13 at 6:16
  • @Arjan Yes debug-02.netdna-cdn.com does work – Louis Hong Aug 1 '13 at 6:36
  • I distinctly recall one chinese based user occationally having trouble with SU and the Great Chinese Firewall – Journeyman Geek Aug 1 '13 at 6:40
  • Note, CDN issues have been very common during the transition to SSL, originally I was certain that's what this was, as more than a trivial amount of people have been experiencing similar behavior. But I can't quite pin this on any of the common causes of that. – Tim Post Aug 1 '13 at 7:03
  • @TimPost I think you may be right, because now that I recall it, over 90% of this happened when I was at work. Who knows what my corporation firewall do about those HTTPS links. I really hope so, after all, github was blocked in China for quite some time last year. – Yu Hao Aug 1 '13 at 7:20
  • It could very well be reacting to mixed content, @YuHao - typically they only get grumpy when you're requesting a page via HTTPS and it pulls in content via HTTP, but some are configured to be very very paranoid. – Tim Post Aug 1 '13 at 7:22
7

It's very likely that something about a firewall you're behind is reacting to the fact that you requested a page via HTTP, but some elements are being pulled in via HTTPS. This may or may not mean:

  • The firewall doesn't like mixed content (even though the requested page was HTTP, and just a few elements are fetched via HTTPS, not the reverse which throws a browser warning)

  • The firewall permits HTTPS only for certain sites that the admins of the firewall trust

  • A mix of the two.

This has been an issue for more than a trivial number of folks since we started rolling out SSL accross the network, an undertaking that is anything but small.

The good news is they're making a ton of progress on it, and hopefully it will be wrapped up in the very near future. Unfortunately, if this is indeed the case, the only thing you can do is talk to the people that control the firewall, and see if an exception can be made.

I'm pretty sure what you're experiencing is related to this, and not a state controlled firewall, although I don't have a way to practically rule it out.

  • 2
    There should be a way to use SE even where all HTTPS is blocked. – Gilles Aug 1 '13 at 7:33
  • 1
    I have tried Stackoverflow over numerous Networks in Beijing. I don't think it's my local firewall note:* NOT on the same Computer * – Louis Hong Aug 1 '13 at 7:35
  • 1
    Easily tested, @Louie. If you cannot access the https: version but the http: version is fine, then at least we know if it's HTTPS related? – Arjan Aug 1 '13 at 8:17
  • FWIW, FB recently rolled out HTTPS everywhere, but still offer plain HTTP in situations where it causes problem like @Gilles suggested. They blogged about it here... makes an interesting read. – Matt Aug 1 '13 at 8:58
  • You're right! It does work when I change the CSS url into (http://)cdn.sstatic.net/stackoverflow/all.css?v=62fd31659efc – Louis Hong Aug 1 '13 at 9:16
  • @TimPost How do I solve this problem though? I know the crew will fix this soon, but what can I do so I can use Stackoverflow without a VPN? – Louis Hong Aug 1 '13 at 9:35
  • @Louie The best I can recommend is use SSH and a browser that can use a SOCKS v5 proxy, but that's not much better than a VPN. I'm going to ask the devs if there's something else you can do (maybe a user script) – Tim Post Aug 1 '13 at 10:42
  • @Gilles I don't disagree, and I think it's just due to this being a 'work in progress' that it's incredibly inconvenient for some. – Tim Post Aug 1 '13 at 10:44
  • @TimPost if the only thing to do is change a few URLs to http://, it's pretty easy to do from a userscript, but it really should be rolled out network-wide. – John Dvorak Aug 1 '13 at 10:45
  • A user script could also replace the CDN URLs with stackoverflow.com/content/js/stub.js and stackoverflow.com/content/stackoverflow/all.css Would anyone know if that's indeed okay? – Arjan Aug 1 '13 at 11:17
4

I have reverted our static content urls to be scheme-relative so that http:// loads http:// from the CDN and a https:// page will load https:// from the CDN, that means Stack Overflow is currently all http://. This should resolve the issue.

Though some pages will be https:// going forward, we're having a discussion internally now about how far we'll go. There are serious performance concerns with SSL (the performance of your page load, any server-side issues are solvable), and there are some trade-offs we are likely not prepared to make. We'll share thoughts on this as soon as we've completed more testing on the full production setup.

  • Nice. Do you happen to understand why embedding HTTPS resources in HTTP pages could have caused these issues, while embedding them in HTTPS pages does not? (If I understand Louie's self-answer correctly.) I think it's not something browsers would go nuts about? (So maybe some badly configured firewall instead?) – Arjan Aug 2 '13 at 14:29
  • 2
    @Arjan many proxies are messed up in many ways, maybe it's checking the referrer header? It could be they have a firewall appliance that check sites then allows content they reference, but not correctly...lots of fail out there we're finding out. – Nick Craver Aug 2 '13 at 14:37
2

Install the Chrome Plugin "Use HTTPS" will temporarily fix the problem. Forcing Chrome to use HTTPS on the white list of the plugin.

https://chrome.google.com/webstore/detail/use-https/kbkgnojednemejclpggpnhlhlhkmfidi

  • So you're saying that using HTTPS for stackoverflow.com itself, also fixes problems in using HTTPS for resources it embeds? (Then maybe you could even just type https:// without the plugin. The certificate is not valid for that site though, but one can ignore that.) – Arjan Aug 2 '13 at 10:27
  • @Arjan Actually I've tried adding HTTPS before and it doesn't work, but this plugin magically fixes everything. Or did StackOverflow fix everything already? – Louis Hong Aug 2 '13 at 17:33

You must log in to answer this question.

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