669982 - Consider serving addon iconURL images from http as well as https

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

In Fennec we display some recommended add-ons in the about:home page - loaded during startup. The page displays the iconURL, name and version of the add-on.

We ran into Ts performance issues with any https access during startup because it loads NSS (which takes non-trivial time to initialize). We cache as much of the data as possible, but the iconURL is still https. At some time i the distant past we changed the iconURL to http and it magically worked. Now it no longer does - we get a 404.

Would it be possible to serve the iconURL from http as well as https so we could continue to use the NSS-free loading during startup?

Comment 1

[Wil Clouser [:clouserw]]

This is an example:

https://static-cdn.addons.mozilla.net/en-US/firefox/images/addon_icon/318202-32.png?modified=1306953054

Up to IT if they want to do this and figure out how.  Allowing anything in /images/ doesn't bother me.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Update ping? This bug affects Fennec 5, 6, 7 and 8

Comment 3

[Jake Maul [:jakem]]

I'm guessing this broke when we switched to Edgecast SSL-CDN for AMO, which is not currently set up for non-SSL access.

I believe we can turn that on, however... I'll talk to mrz and see if this seems okay to do.

Comment 4

[Jake Maul [:jakem]]

Missed mrz today, assigning to him for comment instead.

mrz, do we have any reservations about serving this up over non-SSL-CDN as well as SSL-CDN? It looks to me like the Edgecast ADN can do either, but the fact that we didn't makes me think there may have been a particular reason for not doing it.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Pinging

Comment 6

[matthew zeier [:mrz]]

I'm fine with whatever you think makes sense.  It's not a cost issue.

Comment 7

[Jake Maul [:jakem]]

I've set this up on the CDN. It will take an hour or so to propagate.

There's no good way to restrict which specific content is available over SSL or non-SSL, so it may be that some things which were previously forced to SSL (pre-CDN) may now work without the encryption. It's kinda all-or-nothing... either all of static-cdn.addons.mozilla.net requires SSL, or SSL is optional.

Of course, if you send users 'https://' links, they'll get SSL.

Also, the server-side SSL vs. non-SSL restrictions that have always existed are still in place. I'm not entirely sure how this will affect the CDN. It might trigger the CDN to do the redirect internally, or the CDN might return the redirect all the way to the client. Either way it should still work, but might potentially involve extra redirects. It might be a good idea to keep an eye out for requests that get redirected a lot before getting to the end content.

I will mark this as RESOLVED FIXED. If it seems to still not be working in a couple hours, please re-open. Thanks!

Comment 8

[Wil Clouser [:clouserw]]

Can you paste in the rules you implemented here?  I'm nervous about your "all-or-nothing" statement - we definitely require server side SSL redirection on other parts of the site.  This can only be for /images/

Comment 9

[Jake Maul [:jakem]]

There are no "rules" implemented here, per se. I simply enabled the "HTTP" side of the CDN, and it uses http://static.addons.mozilla.net/ as its origin. This means http://static-cdn.addons.mozilla.net/ should work.

Any redirection rules on static.addons.mozilla.net will still apply, with one caveat.

The caveat is non-obvious: Does the CDN cache HTTP and HTTPS requests separately? If it considers the full URL (with protocol) in its caching decisions, there's no problem. If it strips the protocol before a caching decision, we'll have a big problem- http:// and https:// requests would have the same cache entry. The redirect rules on the server-side would be inconsistently applied- sometimes redirecting inappropriately (causing a loop in the worst case), sometimes not redirecting at all when they should.

My belief is that this isn't a problem, because it's common that sites would want to handle HTTP and HTTPS traffic differently. Therefore, caching engines would likely want to take that into account. However, I will email Edgecast to confirm this.


Here's a scenario:

Client requests http://static-cdn.a.m.n/not-ssl.js from the CDN
CDN forwards the request to the origin like: http://static.a.m.n/not-ssl.js
Server responds to the CDN with a 302 to https:// (1)
CDN forwards the 302 on to the client (2)
Client requests https:// version, from the server or CDN, based on (1) and (2)
CDN or Server responds:
    Server would respond with 302 to CDN, or possibly serve directly (3)
    CDN would serve as normal (from cache, or from server if not cached)


(1) Here's the first hurdle. Does it respond with https://static.a.m.n/not-ssl.js, or https://static-cdn.a.m.n/not-ssl.js ? The distinction being '-cdn'. That is, if the 2 bits of redirect logic are handled separately, then the user will ultimately be redirected twice. This is most likely the case.

(2) Most likely it will not translate the redirect name... that is, if in (1) the server responds with a non-CDN link, then the client will ultimately get a non-CDN link. This might result in the client hitting the server directly, and getting redirected a second time, back to the CDN, but over SSL this time.

(3) This would basically depend on just how thorough the CDN-detection rewrites actually are. I don't remember how this logic works anymore, but I think it's pretty good.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

Seems to be working fine in Firefox Mobile 5, down to the Nightly. Thanks.

Comment 11

[Wil Clouser [:clouserw]]

This isn't working correctly.  As I mentioned above, only /images/ URLs can be served over plain text.  The change you made above allows any URL to be served over http.

This should be reverted until we can get the /images/ only solution.

Comment 12

[Jake Maul [:jakem]]

This is reverted. It will take an hour or so to fully propagate and stop hosting it over HTTP.

I'm not sure why it's broken, though...

Before we had the CDN, weren't there rules in place determining what could and could not be handled over normal HTTP? I don't remember us ever removing those. They should be as effective now as before the CDN went into production.

Per comment 0, this used to work, which would imply that (prior to the CDN) HTTP was allowed for certain URLs. This is what led me to believe that the rules you're referring to were in place and had an exception for /images/. Did we just allow everything over HTTP back then and the CDN changed that behavior?

Comment 13

[Wil Clouser [:clouserw]]

I think oremj added a rule to redirect everything to ssl.  He can answer questions about what rules we have now though.

Comment 14

[Jake Maul [:jakem]]

Assigning to oremj for comment.

Comment 15

[Jeremy Orem [:oremj]]

To get this to work right I think we need to:

* set the origin for CDN http to be http on our end
* modify the https-redirect trafficscript rule to allow /images/

or

* have the CDN send us a header that lets us know if the request is http/https and then create a trafficscript or rewrite rule that redirects to SSL if HTTP and not /images/

Comment 16

[Jeremy Orem [:oremj]]

There is no obvious way to send HTTP traffic to a different origin, so we can tell the difference between the two.  I have filed a support request and will comment when I hear back.

Comment 17

[Jeremy Orem [:oremj]]

curl -vs 'http://static-cdn.addons.mozilla.net/en-US/firefox/images/addon_icon/329794-32.png?modified=1314148085' > /dev/null
* About to connect() to static-cdn.addons.mozilla.net port 80 (#0)
*   Trying 72.21.92.20... connected
* Connected to static-cdn.addons.mozilla.net (72.21.92.20) port 80 (#0)
> GET /en-US/firefox/images/addon_icon/329794-32.png?modified=1314148085 HTTP/1.1
> User-Agent: curl/7.21.3 (i686-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: static-cdn.addons.mozilla.net
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: max-age=315360000
< Content-Type: image/png
< Date: Tue, 06 Sep 2011 18:39:49 GMT
< ETag: "ae1"
< Expires: Fri, 03 Sep 2021 18:39:49 GMT
< Last-Modified: Wed, 20 Jul 2011 20:56:17 GMT
< Server: ECD (lax/2811)
< Via: Moz-Cache-pp-zlb02
< X-Backend-Server: web25
< X-Cache: HIT
< X-Cache-Info: caching
< Content-Length: 2785
< 
{ [data not shown]
* Connection #0 to host static-cdn.addons.mozilla.net left intact
* Closing connection #0


I've redirected everything that isn't :locale/:app/images/.* back to addons.mozilla.org, but I haven't done any extensive testing.