Closed Bug 1083090 Opened 10 years ago Closed 10 years ago

Broken CSS and JavaScript errors with Firefox 33 (regression) [partial transfer]

Categories

(Core :: Networking: HTTP, defect)

33 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox33 + fixed
firefox34 + fixed
firefox35 + fixed
firefox36 + fixed

People

(Reporter: udo.bugz, Assigned: mcmanus, NeedInfo)

References

Details

(Keywords: dev-doc-complete, regression, site-compat)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303

Steps to reproduce:

Open sites that I use daily.


Actual results:

The website should display normally, without errors.


Expected results:

I have two regressions that came up upgrading from Firefox 32 to 33.

First, a MoinMoin v1.9.5 Wiki page is displayed without any CSS rules applied.

The HTML code references a number of CSS files:

<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/wiki/moin_static195/rightsidebar/css/common.css">
<link rel="stylesheet" type="text/css" charset="utf-8" media="screen" href="/wiki/moin_static195/rightsidebar/css/screen.css">
<link rel="stylesheet" type="text/css" charset="utf-8" media="print" href="/wiki/moin_static195/rightsidebar/css/print.css">
<link rel="stylesheet" type="text/css" charset="utf-8" media="projection" href="/wiki/moin_static195/rightsidebar/css/projection.css">

All those URLs are valid (the CSS code shows up when clicking the link in the source code viewer of Firefox.
In the "Network" panel of FireBug I see those URLs being loaded (200 OK status).
However, FireBug claims "no CSS rules defined" in the "CSS" panel.

Furthermore, in the "Console" panel I see JavaScript errors related to undefined functions. I verified that those functions are defined in an referenced .js script:

<script type="text/javascript" src="/wiki/moin_static195/common/js/common.js"></script>

Apparently that script isn't used either.

Similarily, we have problems with OTRS 3.1.11. CSS rules work fine in that case, also JavaScript seems to work somehow. However, the site shows "CommunicationError: Error during AJAX communication" errors when switching between messages. 

Notes:
- Both sites are served from the same, SSL secured domain (it hosts a number of web applications at different subdirectories). 
- The same domain hosts other applications, which work fine (it seems)
- The SSL certificate was issued by Thawte. Firefox doesn't report any problems with the certificate.
- We experience the same problems on three different computers.
- It's definitely a Firefox 33 problem, because not-yet-updated Firefox 32 (on another computer) had no problems - until updated to Firefox 33.
- Tried to clear Firefox cache, didn't make any difference.
- Can't give you the URL of the problematic domain since it is not publicly accessible.
Ah, forgot, the same applications work fine with other browsers, like Chrome.
Could you test:
1) in safe mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
2) with a clean profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Does it fix the rendering issue?

NB/ a website URL with this issue would be good...
Flags: needinfo?(udo.bugz)
Tried both, didn't change anything (same issue with new profile and with safe mode).

I have the same CSS problems when logged out, so you can try yourself:

go to the HTTPS site at secure.indunet.it, subfolder "wiki" (don't want the URL to get crawled easily, so please don't paste the full URL here, please).

Stylesheets don't get applied there (works in Chrome and IE).

BTW, this is on Windows 7 64bit, if that matters.
Flags: needinfo?(udo.bugz)
I didn't find the wiki URL, please, send me it by email, it'll be easier.
NB: your wbesite has a certif issue, I needed to add a certif exception.
Sent via email
Btw, having the same problem on Firefox for Android
Regression range:
good=2014-06-16
bad=2014-06-17
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80431d4fd0da&tochange=bb35d1b73634

Maybe suspected bug:
Daniel Stenberg — Bug 237623
Component: Untriaged → Networking: HTTP
Keywords: regression
Product: Firefox → Core
The server is misconfigured.

https://secure.indunet.it/wiki/moin_static195/modernized/css/common.css

responds:
Content-Encoding: gzip
Content-Length: 11494

but only sends 3560 bytes of data followed by a close. That's a corrupted response and we don't think its safe to honor that for css/js. (several other urls on your site have the same problem.)

(11494 turns out to be the size of the css after ungzipping the 3560 - so the content-length is simply wrong). It appears some module is dynamically applying the gzip in your configuration, it needs to be fixed to adjust the framing information as well.

bug 237623 is indeed the root cause of this - that bug intentionally rejects this kind of broken response as it was silently hiding download errors in the past.

I'm going to wontfix this for now - but thank you for reporting it. I want to see if there is more breakage than anticipated.
Blocks: 237623
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Summary: Broken CSS and JavaScript errors with Firefox 33 (regression) → Broken CSS and JavaScript errors with Firefox 33 (regression) [partial transfer]
Confirmed.

Disabling the mod_deflate module of Apache makes the symptoms go away. Of course, this is a suboptimal solution, but you're right that it's primarily a server problem.

However, see these bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509116
https://bugs.launchpad.net/ubuntu/+source/libapache-mod-fastcgi/+bug/381384

Apparently that's a general problem of mod_deflate in certain configurations. I guess there are several servers that use mod_deflate + mod_fastcgi and thus you might think again if this situation shouldn't perhaps handled gracefully.

Also, it would be nice if Firebug / the integrated developer console would at least say something about the broken HTTP request. After all, valid data has been received, but the HTTP connection theoretically just was incomplete.
for reference if we get duplicates - the debian bug report says "Switching from libapache2-mod-fastcgi to libapache2-mod-fcgid allows dynamic content to be correctly served."
You've just made a lot of web pages undisplayable.
It wouldn't be as bad if there was any way to revert to the previous firefox version.

Getting web server software/configurations updated isn't easy at all, especially in the short term.

Allowing the 'incorrect' length if it matched after decompression would cover the security issues while leaving the pages viewable.
If this is actually something that happens in common enough webserver configurations, then we should seriously reconsider bug 237623...

That said, the fact that we didn't get bug reports until release suggests it's not in fact very common.
This "fix" is killing us. We can no longer download documents from a lot of federal and state agencies. This isn't just an Apache issue. We are seeing it when accessing IIS servers also.
matt - can you give some urls?
Just a thought: I haven't time to look at the source yet, but is this fix incompatible with chunked transfer encoding?
(In reply to Matt Helm from comment #18)
> Just a thought: I haven't time to look at the source yet, but is this fix
> incompatible with chunked transfer encoding?

it works fine with chunks. Its incompatible with server broken framing (both content-length and chunked) - which is an error we tolerated before but tolerating it caused us a number of other problems which are now resolved.

as I said - we'll be evaluating the bug reports to see if it is having a bigger impact that we thought. 

thanks for the state.nj link.. I haven't looked at it yet - but I will take a look to make sure the issue is that the server's response is badly formed. That has been the case for each report so far.
Thanks, I was just glancing at the 188881:bb7ae1cc7789 changeset and saw that chunked encoding was accounted for. I should have known that it wasn't that easy.

This sucks extra bad because we will have have to switch browsers company wide or rollback FF versions and turn auto updating off.

Getting .gov to fix broken servers is an effect as tilting at windmills.

An about:config setting to ignore invalid content or chunk length would be handy.
We are also seeing this issue on IIS servers throughout our clientbase with FF 33 (latest build).  we may be able to resolve the server configuration in our next update, but just wanted to add support to the "it's affecting a lot of people" side.
This online tool migth come handy when checking servers:
http://www.gidnetwork.com/tools/gzip-test.php

For some reason it won't connect to the URL given in comment 17, though.
This is also causing us and our clients some major issues.  We are using IIS.  We have never had an issue before with any FF updates.  It's always IE that causes us problems.  Please let us know a work around!!  Code samples for writing files to the browser with a filestream using the new configuration would be awesome!
(In reply to khosty from comment #23)
> This is also causing us and our clients some major issues.  We are using
> IIS. 

It'd be very helpful if you could clarify exactly which problem you're talking about. Is it pages delivering data of another size than Content-Length says, is it a broken chunked decoding or is it something else?

Without more data we might not be talking about the same problem, and with data we can better understand which parts that cause the most suffering and thus help us decide how to act going forward.
(In reply to Daniel Stenberg [:bagder] from comment #24)
> (In reply to khosty from comment #23)
> > This is also causing us and our clients some major issues.  We are using
> > IIS. 
> 
> It'd be very helpful if you could clarify exactly which problem you're
> talking about. Is it pages delivering data of another size than
> Content-Length says, is it a broken chunked decoding or is it something else?
> 
> Without more data we might not be talking about the same problem, and with
> data we can better understand which parts that cause the most suffering and
> thus help us decide how to act going forward.

Yup, that would have been helpful huh?  Sorry.  Pages delivering data of another size than Content-Length.  Thanks!
the url in comment 22 is also invalid chunked encoding without the required EOF 0 length chunk.
I'm going to make a change to increase compatibility here. I haven't quite decided what it will be - I'm hoping for something better than just a complete reversion of the partial transfer logic because that of course solves a different, but also real, problem.

This is the most concerning case - because it appears to be the exact same thing as an aborted transfer.. a bunch of legitimate HTTP bytes and then an unexpected TCP close.

At least in the case of the gzip problem, as another commentator has pointed out, we could query the gzip layer to see if the decoding was complete there and suppress the partial-transfer error in that case.. but that doesn't solve the chunked issue.
Thank you for looking into this. I am also having this issue at my company's site with Firefox 33 using IIS. I created a basic page here (http://www1.twu.ca/reporting/downloaderror) that returns an empty .csv file to the browser. It works okay in Chrome and Internet Explorer. I tried using the link from comment 22 but it isn't appearing helpful since in reality the site will redirect you to HTTPS but when I enter in the page URL with HTTPS that tool fails to connect to the page. Let me know if it is helpful for me to post more info.
Depends on: 1088850
(In reply to Patrick McManus [:mcmanus] from comment #27)
> I'm going to make a change to increase compatibility here. I haven't quite
> decided what it will be - I'm hoping for something better than just a
> complete reversion of the partial transfer logic because that of course
> solves a different, but also real, problem.

Looks like this bug needs to be reopened. If you're going to make a change in another bug, can you please provide a reference when you resolve this one again?

Patrick - I have assigned the bug to you as I take it from what you wrote that you're taking it.
Assignee: nobody → mcmanus
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
resolved by 1088850
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
I am still experiencing the issue with Firefox 33.0.2: I cannot download some PDFs and get the error message as described in bug 1085094, and from the change log I would have expected this to be fixed with this release.

Can we have some feedback on that? Do you need more info?
(In reply to Nikolaos Kornaros from comment #32)
> I am still experiencing the issue with Firefox 33.0.2: I cannot download
> some PDFs and get the error message as described in bug 1085094, and from
> the change log I would have expected this to be fixed with this release.
> 
> Can we have some feedback on that? Do you need more info?

I guess the bugfix will be in the next 33.1.
I encounter the same issue (broken CSS and JS resource files) with FF 33.1.
I noticed that enabling cache solved the issue (i was in no cache mode).
(In reply to Damien from comment #36)
> I encounter the same issue (broken CSS and JS resource files) with FF 33.1.
> I noticed that enabling cache solved the issue (i was in no cache mode).

As this bug is fixed, could you file a new bug report, please. It would be nice if you can add a testcase (or public URL to test).
Flags: needinfo?(damien.tabardel)
Would this fix be in Firefox ESR 38?

https://www.dropbox.com/bad_files_check

console.error: 
  Protocol error (unknownError): Error: Request failed with status code = 2152398920 in onStopRequest handler for url = https://fonts.googleapis.com/css?family=Open+Sans:100,200,300,400,600,700
console.error: 
  Message: Error: Request failed with status code = 2152398920 in onStopRequest handler for url = https://fonts.googleapis.com/css?family=Open+Sans:100,200,300,400,600,700
The fix should be in ESR 38. Your issue might be different. Would you mind filing a new bug?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: