Closed Bug 512570 Opened 15 years ago Closed 13 years ago

Create static.addons.mozilla.org

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
All
Other
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 648146

People

(Reporter: rdoherty, Unassigned)

References

Details

One easy way to speed up a website is to server static content off of a separate, cookieless domain. This allows the browser to open up more HTTP connections and reduces the amount of cookies sent upstream.

Could we have a domain like static.addons.mozilla.org setup and have it simply serve CSS, JS & images? 

The only caveat is AMO currently serves add-on images out of the db. We'd have to either serve those images from amo or somehow allow add-on image requests to the static site hit PHP. (but not any other requests except for static files)
1. Is there a webdev bug on getting images out of the database?

2. This has to be over SSL too right and over an EV cert right?  Otherwise addons.mozilla.org won't show as EV?
(In reply to comment #1)
> 1. Is there a webdev bug on getting images out of the database?
Heh, *sigh*, yeah,  bug 482837

> 2. This has to be over SSL too right and over an EV cert right?  Otherwise
> addons.mozilla.org won't show as EV?
Yeah.  The AMO cert isn't wildcard is it?
> > 2. This has to be over SSL too right and over an EV cert right?  Otherwise
> > addons.mozilla.org won't show as EV?
> Yeah.  The AMO cert isn't wildcard is it?

addons.mozilla.org isn't (or won't be - it's supposed to be EV).  There is a *.addons.mozilla.org cert but it's not EV.  

If this really improves performance and is Good Thing we might need to pick up another EV cert for static.addons.mozilla.org.
Depends on: 482837
Will mixing a non-EV cert with the EV one throw a warning or anything?  /me doesn't know the details of all that but this would be a good (albeit, lower priority) thing.
(In reply to comment #3)
> If this really improves performance and is Good Thing we might need to pick up
> another EV cert for static.addons.mozilla.org.

I think it will improve performance :)
http://www.ajaxperformance.com/2006/12/18/circumventing-browser-connection-limits-for-fun-and-profit/
(In reply to comment #4)
> Will mixing a non-EV cert with the EV one throw a warning or anything?  /me
> doesn't know the details of all that but this would be a good (albeit, lower
> priority) thing.

Fligtar asked me in email, sorry I missed the discussion here until now. My reply to him in email:

It's a bit of a hot topic right now, with some researchers arguing we should be more forceful than we are, but the current answer is: as long as it's valid SSL, subelements of an EV page using non-EV certs will not degrade the EV status, or ring any alarm bells in Firefox, IE, or Chrome. Don't know about Safari, but I suspect they're in the same boat - and Opera makes it an option to degrade the status, but ships with the same default that we do.
Looks like the url will have to be something not on the addons.mozilla.org domain. All cookies set for a subdomain are sent to that subdomain's subdomains (confusing, I know).

Something like amocdn.com or amoimg.com will work (although the EV cert stuff will probably be a problem).
Severity: minor → enhancement
Curious what the scheduling is for this. Q3, Q4?
Q4.
wfm :)
(In reply to comment #7)
> Looks like the url will have to be something not on the addons.mozilla.org
> domain. All cookies set for a subdomain are sent to that subdomain's subdomains
> (confusing, I know).

That's not true if AMO is doing cookie handling correctly. For example, bmo uses subdomains for attachments just so cookies are not accessible by attachments. My guess is that AMO purposely did cookies this way so FAMO and SAMO could access them. Seems like an alternative approach is necessary to solve this issue, such as AMO possibly setting cookies for those subdomains itself rather than for all of .addons.mozilla.org. A separate domain would also work, as you pointed out.
Combine this with dave's work in bug 482837 and we'll have more free cycles than we know what to do with. ;)

but seriously, it should be easy to serve all images off another domain once they are on disk.
Did we ever decided on the SSL requirements?  

Did we decided on the hostname?  static.addons.mozilla.org?

Seems like a perfect use for EdgeCast, with either them as origin or us.
(In reply to comment #13)
> Did we ever decided on the SSL requirements?  
We know we need some SSL.  If we (and the other browser vendors) aren't planning on changing the behavior described in comment 6 we can use a regular cert.  If we want to start a best practice where using 1 EV cert means you use an EV cert for external resources also we should buy another EV cert or a wildcard one.  

Johnath:  I think you're the closest to the debate on this - do you think our current implementation will change in the future?  Is it a good idea to get an additional EV cert now to be prepared?
(In reply to comment #14)
> Johnath:  I think you're the closest to the debate on this - do you think our
> current implementation will change in the future?  Is it a good idea to get an
> additional EV cert now to be prepared?

It's unlikely to change for 3.6, anyhow.

There are some documented attacks out there where people have fraudulently obtained non-EV certs and used them to subvert an EV site by impersonating sub-content. My personal feeling is that we should clean up the (non-EV) CAs issuing those certs rather than just throwing away the whole idea of trusting non-EV certs. It's certainly possible that we would further restrict our EV behaviour in the long run, though, if the problems kept occurring.

Having said that - our existing EV CA should be able, on relatively little notice, to issue a new EV cert for the subdomain should the need arise. They have already verified all our corporate information, so I'd expect it to be a (relatively) simple matter to either cut a new cert or add the subdomain to the existing cert (EV certs don't permit wildcards). So I don't think there's a lot of sense to getting one now, defensively.

If Firefox changed behaviour here in anything other than a firedrill situation, you'd have at least a month or two before the change went live, which should give you the time you need to get a new cert cut.
(In reply to comment #13)
> Did we decided on the hostname?  static.addons.mozilla.org?

I recommend against using static.addons.mozilla.org (comment #7). Cookies will currently be sent to that domain, which will slow down fetching resources. Since cookies are used for addons.mozilla.org, SAMO and FAMO, changing how we send cookies to those services would be problematic if not impossible. 

I recommend something like amocdn.com or mozcdn.com. Bonus points for using mozcdn.com/amo/, that way we can re-use the domain for hosting static assets of our other websites.

Even more bonus points if we set it up like Akamai where you use urls like:
https://mozcdn.com/https://addons.mozilla.org/img/foo.gif. The cdn would fetch the resource from the supplied url (whitelisted), cache it and send to the user.
I don't know if we need a separate domain but I get your point (it'll be something under mozilla.net or mozilla.com more likely).

My SSL questions were mostly CDN related in terms of SSL transactions/second.
(In reply to comment #17)
> I don't know if we need a separate domain but I get your point (it'll be
> something under mozilla.net or mozilla.com more likely).

The benefits of using a separate domain will be noticeable. Both AMO & moz.com have about 500 bytes of cookies, which are sent upstream on every request. ~50 requests x 500 bytes = 25k of data users have to send back to us. 

Since user's upload speeds are a lot slower than download, sending 25k of less data can mean a couple hundred milliseconds to a second or two of extra time loading a webpage.
Whiteboard: [blocked]
AMO is at the start of another release cycle and being able to use this would be nice. It looks like we need a domain name.  mrz - can you sum up anything else we need?  Were your SSL questions answered?
You're right - you need a hostname.  Matters little to me.  If it's a cookie issue, something under mozilla.net would be best.

This bug is unassigned only because we're blocked on bug 482837.
(In reply to comment #20)
> You're right - you need a hostname.  Matters little to me.  If it's a cookie
> issue, something under mozilla.net would be best.

I'll get one today.

> This bug is unassigned only because we're blocked on bug 482837.

I don't think we're blocked on that bug.  We can use this with or without that, and we can prepare this beforehand too.  If anything it seems like this would block that.
(In reply to comment #21)
> (In reply to comment #20)
> > You're right - you need a hostname.  Matters little to me.  If it's a cookie
> > issue, something under mozilla.net would be best.
> 
> I'll get one today.

We're happy with static.mozilla.net
I'm going to suggest amo.static.mozilla.net and I'll get a wildcart cert for *.static.mozilla.net.  Might use this for something else too, other than just amo.

I believe the discussion is leaning towards using an OU SSL cert and upgrading to EV later if it becomes necessary.  Any objects (johnath)?
(In reply to comment #23)
> I'm going to suggest amo.static.mozilla.net and I'll get a wildcart cert for
> *.static.mozilla.net.  Might use this for something else too, other than just
> amo.

I think we were going to do namespacing like s.m.n/a.m.o/___, but it doesn't matter to us where we do it.  Whatever is easiest for you.

I'll CC davedash here because he had an idea for doing this in vhosts, but I don't want to clutter this bug so once there is an assignee for the bug can we talk on IRC about the best way to do it?
(In reply to comment #23)
> I'm going to suggest amo.static.mozilla.net and I'll get a wildcart cert for
> *.static.mozilla.net.  Might use this for something else too, other than just
> amo.
> 
> I believe the discussion is leaning towards using an OU SSL cert and upgrading
> to EV later if it becomes necessary.  Any objects (johnath)?

Nah, see comment 6 - as long as the top level page is EV and the sub-elements are SSL (EV or OV or DV - anything signed by a CA) we should be good, here. Possibly subject to eventual change, but not in a way that should block you now, and I'd warn AMO in advance anyhow.
Assignee: server-ops → jeremy.orem+bugs
Whiteboard: [blocked]
Matthew, did you ever purchase the *.static.mozilla.net cert (or even just *.mozilla.net)? 

Setting up SSL wrapped CNAMES in edgecast doesn't look like a regular operation. How did you do it before?
No, I didn't do anything.  Send me a CSR for whatever.

EdgeCast does a SAN cert on their side (and not wildcards).  Let me know what domain needs to be added there (though I think you can file a support ticket through their portal).
Assignee: jeremy.orem+bugs → mrz
Fell off my plate.  I'm working with EdgeCast to get static.addons.mozilla.net added to their SSL SAN certificate.
Whiteboard: [edgecast]
Assignee: mrz → jeremy.orem+bugs
Turns out edgecast w/ssl is too expensive. I can host this domain right now and point it at addons. Worth it? How long would it take to make addons media url configurable?
It already is on zamboni.  I don't expect to change remora to add the URL.  So, we could use it whenever it's ready although traffic will be lower than projected for a couple months.
Component: Server Operations: Web Content Push → Server Operations: Projects
I'm trying to plan our Q2 schedule - is there an ETA for this?
talked to wil, part of IT's q2 goals already so certainly q2.
Whiteboard: [edgecast]
It would be pretty easy to just point addons-cdn.mozilla.net -> amo right now. Want me to?
I told the AMO devs that we can assume this will be up and running with both HTTP and HTTPS to support the personas stuff by the middle of April.

Does that timeline work for you guys?  If not, we'll have to delay the personas front end launch because of the SSL discussions.

> It would be pretty easy to just point addons-cdn.mozilla.net -> amo right now.
> Want me to?

Depends on the timeline above.  It's not critical yet. :)
Safe to assume.  The personas gallery issue worked itself out (tentatively anyways).
Is this setup in a fashion that we can test?  

Interested in this for two reasons:
1. decrease log volume.  if we don't do metrics on images/css/js, we can reduce the log file sizes and speed up transfers and analytics.

2. CDN SSL testing - would like to offload images/css/js to a CDN (or at least start testing with it).

What has to happen to support this?
If the app is ready we just need a domain name and a cert. I assume we'd just set it up like the personas CDN.
Nice.  I'll wait on the app guys to tell me!
(In reply to comment #38)
> Nice.  I'll wait on the app guys to tell me!

The app guys are ready to go.  If you're ready by next week we should flip preview.amo to start using the CDN to make sure things are working; that will give QA time to poke around.  

On our end it will just be checking out the /media directory of either trunk, preview or next.

May 5th would be a good date for us.
I suspect for the SSL testing we'll use whatever SSL cert -they- have so I'm hoping the CDN url is easy to configure.  If it actually works, then we'll go through and get a real cert.
Ah, it should be just a matter of setting a config variable for our new code[1].  Definitely something to test though. :)


[1] http://github.com/jbalogh/zamboni/blob/master/settings.py#L338
We will soon be serving up static ssl content via ssl cdn.  When Jake is done with that I'm pretty sure this bug will be satisfied..?
Assignee: jeremy.orem+bugs → server-ops
Component: Server Operations: Projects → Server Operations
(In reply to comment #42)
> We will soon be serving up static ssl content via ssl cdn.  When Jake is done
> with that I'm pretty sure this bug will be satisfied..?

This bug, as filed, is already satisfied by using StAMN.  I'd close it.
I'm okay with closing this as well- see Bug 648146 for more info. Closing... please re-open if there are any concerns about this not addressed in the aforementioned bug.

TL;DR: preview (addons.allizom.org) is already moved over to Edgecast's ADN- as it's only staging, we did not pay them extra to get it included in the cert used, so you'll need to allow the exception (QA has done so). Production is ready to go as well, with a good cert- static-cdn.addons.mozilla.net. Once QA approves the change in preview, we can change STATIC_URL on production to make this live.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Resolution: FIXED → DUPLICATE
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.