Closed Bug 222457 Opened 21 years ago Closed 20 years ago

Using gzipped content over ssl, when css is gzipped from the web server, css fails to render with page. JS and HTML render fine

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 227976

People

(Reporter: sjacobs, Assigned: dbaron)

References

Details

Attachments

(2 files)

HTTP Session log of failing CSS render.
68.23 KB, text/plain
Details
HTTP session trace
2.32 KB, text/plain
Details 
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... :(
Attached file HTTP session trace — 
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 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: