1084395 - Style sheet fails to load, and it isn't clear why

Status: RESOLVED DUPLICATE of bug 1083090

(Core :: Networking: HTTP, defect)

Description

[Marc Bernard]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36

Steps to reproduce:

I have a page that loads two style sheets. One loads fine, but the other doesn't. I see it downloaded ok in the network tab, but the developer tools Style Editor reports "Style sheet could not be loaded". If I copy the content of the style sheet that does not load into the one that does load, everything is fine.

This worked as expected on Firefox 32.


Actual results:

When I open the Browser console I see an error:

GET http://localhost/ [HTTP/1.1 200 OK 20ms]
GET http://localhost/general.css [HTTP/1.1 200 OK 0ms]
GET http://localhost/theme.css [HTTP/1.1 200 OK 80ms]
Error: Request failed with status code = 2152398924 in onStopRequest handler for url = http://localhost/general.css?v=2015.1-SNAPSHOT&language=en_US
Stack trace:
fetch/streamListener.onStopRequest@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/stylesheets.js:1191:29
 protocol.js:854
Error: Request failed with status code = 2152398924 in onStopRequest handler for url = http://localhost/general.css?v=2015.1-SNAPSHOT&language=en_US
Stack trace:
fetch/streamListener.onStopRequest@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/stylesheets.js:1191:29
 protocol.js:854
"unknownError" protocol.js:16


Expected results:

Style sheet should be loaded, or a more informative message displayed. If the problem is on my end, it's not clear what the problem is, or where I should look to fix it.

Comment 1

[Matthias Versen [:Matti]]

Is there a public URL available to test this ?
Can you please try it again with a new profile: http://support.mozilla.org/kb/Managing%20profiles ?

Comment 2

[Marc Bernard]

There is a public server available:
http://alpha.demoxero.com/

No need for an account - it happens on the login page too.

I will try it with a new profile.

Comment 3

[Marc Bernard]

Same problem with a new profile.

Comment 4

[Matthias Versen [:Matti]]

Last good nightly: 2014-06-16
First bad nightly: 2014-06-17

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80431d4fd0da&tochange=bb35d1b73634

I suspect bug 237623 but doing local builds now to confirm this

Comment 5

[Matthias Versen [:Matti]]

last good build
https://hg.mozilla.org/mozilla-central/rev/589789cf7bf8
first bad build
https://hg.mozilla.org/mozilla-central/rev/2707ae2da0eb

bug 237623 confirmed to cause this issue.

It could be that this is a similar issue as bug 1083090

Comment 6

[Patrick McManus [:mcmanus]]

 http://alpha.demoxero.com/style/general.css?v=5.0.583&language=en_US

its served with a content-length header of 7956, but only 2404 bytes of content. It turns out the css is gzipped. Whatever applied the gzip failed to adjust the content length. That's a server side bug.

We've started calling that an error because our previous policy of ignoring the error lead to saving of silently truncated downloads and application of truncated css and js (which you can see how could be a security hole - applying only part of a policy).

any chance you're using mod-fastcgi? There is a bug report against that which can be repaired by using mod-fcgid instead.

Comment 7

[Marc Bernard]

Thanks for checking into this - I'll follow up with our server guys.

It would be great if there was a little more feedback as to the cause of the problem, since the "Style sheet could not be loaded" doesn't really tell me any more than I already knew. Something simple like "content length doesn't match" or whatever bone could be thrown.

Comment 8

[udo.bugz]

Have a look at comment 8 of the referenced bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1083090#c8

It seems your server is compressing some HTTP requests with gzip (which is fine) but sends an incorrect Content-Length header. If the assumption is correct, the server indicates the number of *uncompressed* bytes (prior gzip compression) but the spec says that Content-Length should match the *compressed* size. Newer versions of Firefox treat that (correctly) as an error, while older versions accepted the (based on headers technically incomplete) request anyway.

It looks that it's a common bug with Apache and mod_deflate, especially in combination with mod_fastcgi.

Your server guys should check if the server is using a similar configuration - and perhaps replace mod_fastcgi with mod_fcgid to solve the problem. Maybe some info about your server config would help, too.