User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 While working on an internal site, I enabled Apache::Dynagzip in my server with fixupclients. Everything worked fine, until I switched the site to SSL. When in SSL mode, mozilla does not render pages with their stylesheets. It does render the html with any included javascript files though. Reproducible: Always Steps to Reproduce: 1. Design an HTML page with CSS included in a seperate file. 2. Serve it from a web server using gzip compression over an SSL connection 3. Watch your page look really really ugly Actual Results: Page is rendered without CSS Expected Results: Rendered the page with CSS, as it does over a normal http connection. (IE, uncompress the page and included it) I have tested this on linux / Mac OSX / and Windows XP with Mozilla 1.5 release. All three fail in exactly the same way.

is there a public web site to test with ? Otherwise, can you attach a HTTP log via "create a new attachment" from a failing session ? See instructions here: http://www.mozilla.org/projects/netlib/http/http-debugging.html

I will generate an attachment tonight. No public website is available for this unfortunately. I could rig a demo if necessary though.

Steve? Any news here?

I have deleted some hostname information about the connecting server, if this is a problem let me know. Sorry it took so long to get this to you guys.

I assume we're talking about "/css/formatting.css" and so forth? The headers coming back for that request are, as far as I can tell: 872[a56010]: http response [ 872[a56010]: HTTP/1.1 200 OK 872[a56010]: Date: Mon, 27 Oct 2003 00:11:33 GMT 872[a56010]: Server: Apache/1.3.28 (Unix) mod_perl/1.28 mod_ssl/2.8.15 OpenSSL/0.9.6i 872[a56010]: X-Module-Sender: Apache::Dynagzip 872[a56010]: Expires: Monday, 27-October-2003 00:16:33 GMT 872[a56010]: Transfer-Encoding: chunked 872[a56010]: Vary: Accept-Encoding 872[a56010]: Keep-Alive: timeout=15, max=98 872[a56010]: Connection: Keep-Alive 872[a56010]: Content-Type: text/html 872[a56010]: Content-Encoding: gzip 872[a56010]: ] There could be a few issues here: 1) Is the data actually chunked-encoded like it claims? 2) Is the page in standards mode? The CSS is returned as text/html. Check your JS console for an error regarding that?

Steve? Could you answer my questions from comment 5? Especially question 2?

*** Bug 243005 has been marked as a duplicate of this bug. ***

I am having this same issue. I am running Apache 2 with gzip turned on using Firefox 0.9.1. When I browse to http://www.wadesound.com/ then the CSS renders fine. However, when I browse to https://www.wadesound.com/ then the CSS fails to render.

Here is some header output: GET / HTTP/1.1 Host: www.wadesound.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: user_id=853fee5cf086f4e3872938fb0b08aa32; PHPSESSID=757149b4d9f28b78994c035b6a8dfb6a Pragma: no-cache Cache-Control: no-cache HTTP/1.x 200 OK Date: Fri, 02 Jul 2004 09:34:02 GMT Server: Apache/2.0.49 (Gentoo/Linux) PHP/4.3.6 mod_ssl/2.0.49 OpenSSL/0.9.7d X-Powered-By: PHP/4.3.6 Set-Cookie: PHPSESSID=757149b4d9f28b78994c035b6a8dfb6a; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 5772 Keep-Alive: timeout=15, max=54 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 ---------------------------------------------------------- https://www.wadesound.com/docs/main.css GET /docs/main.css HTTP/1.1 Host: www.wadesound.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Accept: text/css,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://www.wadesound.com/ Cookie: user_id=853fee5cf086f4e3872938fb0b08aa32; PHPSESSID=757149b4d9f28b78994c035b6a8dfb6a Pragma: no-cache Cache-Control: no-cache HTTP/1.x 200 OK Date: Fri, 02 Jul 2004 09:34:02 GMT Server: Apache/2.0.49 (Gentoo/Linux) PHP/4.3.6 mod_ssl/2.0.49 OpenSSL/0.9.7d Last-Modified: Tue, 18 May 2004 06:19:30 GMT Etag: "3c909-df8-ecab2080" Accept-Ranges: bytes Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 579 Keep-Alive: timeout=15, max=62 Connection: Keep-Alive Content-Type: text/css

Note: Javascript console shows no error, the CSS is returned as text/css and this problem seems intermittant. It also seems to affect Javascript manipulation of IFRAME content, leading me to think that something with the gzip is choking when it trys to load external content from an SSL session.

The https url in comment 8 works for me (just reloaded 6 times in a row and it's fine every time).

I should mention that, because of this problem, I have turned off GZIP compression for all CSS and JS files on the site http://www.wadesound.com/ > The https url in comment 8 works for me (just reloaded 6 times in a row and it's > fine every time).

Meaning there is no way to test this, huh? Makes it hard to fix... :(

I have the same issue here using mozilla 1.7.5 and firefox 1.0 I attached an HTTP session trace captured with LiveHTTPHeaders 0.10/Firefox.

Need a test site to keep sending the gzipped content and headers over SSL, and then we can probably enable/add enough debugging hooks to figure this out. Is this really a Style System bug, or should it go to Necko? /be

The URL exposed in the attachment i just added may be used to do some tests. Be warned that my upstream bandwidth is limited to 16kB/s, so please do not do crazy things ;)

The url in the attachment of comment 14, the style loads fine in a 1.8a3 Windows build (all I have over here for the moment)... At least the "Home" link is bold, which indicates that the style loaded.

Part of the problem is that it does not appear every times, some times the CSS is used (and will be despite several crtl+r), and some times it is not (and several crtl+r will rarely help). I just did retried that URL : - started Firefox 1.0/Linux - several GET $url -> CSS ok. - cleared firefox cache - re-started firefox - several GET $url -> CSS !ok. - restarted firefox (without clearing cache) - several GET $url -> CSS ok. - restarted firefox - several GET $url -> CSS !ok - restarted firefox - several GET $url -> CSS !ok - cleared firefox cache - restarted firefox - several GET $url -> CSS !ok

(In reply to comment #17) > At least the "Home" link is > bold, which indicates that the style loaded. Yes. And if the style does not load, every links will be underlined. If the CSS loads, links will appear without any decoration and will turn "red on grey" on mouse hover.

Is there anything you can do to make this reliably reproducible? Maybe have the CSS file be script-generated and send it one char at a time with a 0.1 second sleep between chars or something?

*** Bug 277104 has been marked as a duplicate of this bug. ***

I do not know how exactly apache and mod_gzip work internaly, but won't they buffer the output of my CGI, thus hiding the delays on the browser side? Anyway i tried that and it does not appear to change the fact that sometimes it works ok and sometimes it fails. But, this way, it seems i get a failure *much* more often. /ssl-css-gzip-test/index-cgi.html uses /ssl-css-gzip-test/cgi/css.cgi as a CSS source while /ssl-css-gzip-test/index.html uses the regular file /ssl-css-gzip-test/style/boam.css. css.cgi is a python script that output the regular CSS file char by char with a 0.1s delay between each chars. Doing some tests remotely (from outside of my LAN, thru aDSL), i get the same behaviour (much higher failure frequency) using the regular CSS file too. Maybe the problem is somewhat related with initial network latency while fetching the CSS (just a wild guess..) ?

OK. I finally noticed that all the people seeing this bug are using Firefox 1.0 and tried a gecko build from way back then. That showed the bug. A bit of digging showed that the bug is present in a 2004-06-16-07 build but is fixed in a 2004-06-17-07 build. Looking at the list of checkins between the two, bug 227976 jumps out at me (see its duplicate bug 245608, which is exactly like this bug, and note that when I don't see this bug I see an NS_ERROR_UNEXPECTED dumped to the terminal where I started Mozilla, which is exactly what bug 227976 would cause). So marking duplicate; this is fixed in current builds, which explains why I kept being unable to reproduce it... ;) *** This bug has been marked as a duplicate of 227976 ***