Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convergence 0.08 breaks style sheets on addons.mozilla.org #125

Closed
curtisko opened this issue Nov 28, 2011 · 5 comments
Closed

Convergence 0.08 breaks style sheets on addons.mozilla.org #125

curtisko opened this issue Nov 28, 2011 · 5 comments

Comments

@curtisko
Copy link

Name: Firefox
Version: 10.0a2
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111128 Firefox/10.0a2

Convergence Version: 0.08

Steps to reproduce:

  1. Install Convergence Version 0.08 (may need to mark add-on as compatible)
  2. Navigate to https://addons.mozilla.org

Results:
Page is displayed as a flat HTML file with no images, graphics or the "normal" layout

Expected Results: Page layout and style sheets should not be affected

@tg--
Copy link

tg-- commented Nov 30, 2011

Can confirm this on firefox 8, Linux.
Reason is, that with convergence, the AMO webserver for their CSS ( https://static-cdn.addons.mozilla.net/media/css/impala/ )throws an Error 400, which would indicate a bad http request.

This is the HTTP Request with Convergence enabled:

Host: static-cdn.addons.mozilla.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,_/_;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: UTF-8,*
DNT: 1
Connection: keep-alive
If-Modified-Since: Tue, 16 Aug 2011 23:12:23 GMT
If-None-Match: "86+gzip"
Cache-Control: max-age=0

AMO response (bad):

Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 30 Nov 2011 22:55:31 GMT
Server: ECDF (fra/5959)

Here the request with convergence disabled:

Host: static-cdn.addons.mozilla.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,_/_;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: UTF-8,*
DNT: 1
Connection: keep-alive
If-Modified-Since: Tue, 16 Aug 2011 23:12:23 GMT
If-None-Match: "86+gzip"
Cache-Control: max-age=0

AMO response (good):

Cache-Control: max-age=315360000
Content-Encoding: gzip
Content-Type: text/css
Date: Wed, 30 Nov 2011 23:16:44 GMT
Etag: "86+gzip"
Expires: Sat, 27 Nov 2021 23:16:44 GMT
Last-Modified: Tue, 16 Aug 2011 23:12:23 GMT
Server: ECD (fra/5954)
Vary: Accept-Encoding
Via: Moz-Cache-pp-zlb02
X-Backend-Server: web20
X-Cache: HIT
X-Cache-Info: caching
Content-Length: 96

As you can see, no difference. HTTP headers were read with firebug, no clue if they might be broken somewhere else.

@moxie0
Copy link
Owner

moxie0 commented Dec 11, 2011

Maybe an SNI thing?

@ewanm89
Copy link

ewanm89 commented Dec 11, 2011

SNI usually ends up with us making a cert for the wrong domain, that is not happening here.

@tg--
Copy link

tg-- commented Dec 23, 2011

I was just looking into the issue again, only to find out, that it is gone :)
I recently updated to the current stable release, 9.0, while convergence is still at 0.08, so it either has been fixed upstream (might include newer releases from beta, aurora to nightly), or it has been fixed on server side. Can't really tell, now that it works.

@moxie0
Copy link
Owner

moxie0 commented Jan 1, 2012

Eh, I'm happy to ignore this then. =)

@moxie0 moxie0 closed this as completed Jan 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants