591028 - Port /downloads to zamboni

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect, P3)

Description

[Jeff Balogh (:jbalogh)]

This currently lives at http://viewvc.svn.mozilla.org/vc/addons/trunk/site/app/controllers/downloads_controller.php?view=markup.

I want to switch it so we stop getting hash errors with downloads.  If zamboni makes the buttons and serves the downloads there's no room for inconsistency.

r?wil and r?fligtar because I saw your fingers on this.  AFAIK the new version matches remora in every way except the handing of unreviewed add-ons.  That ?confirmed thing is pointless now that we have the popups.

http://github.com/jbalogh/zamboni/commit/0780aff

Comment 1

[Justin Scott [:fligtar]]

Mossop is going to give us the details for the hash header that we should start using here too. It will fix a number of problems with installing add-ons in Firefox 4 and make non-JS installations safer.

Comment 2

[Dave Townsend [:mossop]]

(In reply to comment #1)
> Mossop is going to give us the details for the hash header that we should start
> using here too. It will fix a number of problems with installing add-ons in
> Firefox 4 and make non-JS installations safer.

Files bug 591070, will follow up with specifics on the hash header in a bit.

Comment 4

[Wil Clouser [:clouserw]]

I'll look at your patch soon

Comment 5

[Jeff Balogh (:jbalogh)]

Reviewed, waiting on the dependent bug.

Comment 6

[Justin Scott [:fligtar]]

The hash fix needs to land before Firefox 4 goes to RC. That means this should be sooner than 4.x or we need to backport it to remora.

Comment 7

[Wil Clouser [:clouserw]]

(In reply to comment #6)
> The hash fix needs to land before Firefox 4 goes to RC. That means this should
> be sooner than 4.x or we need to backport it to remora.

Ah, ok.  thanks.  jbalogh: why does this depend on getting an AMO file server?

Comment 8

[Jeff Balogh (:jbalogh)]

(In reply to comment #7)
> Ah, ok.  thanks.  jbalogh: why does this depend on getting an AMO file server?

Because we don't want to have a python process locked up serving a file.  File servers can do that much more efficiently.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #8)
> (In reply to comment #7)
> > Ah, ok.  thanks.  jbalogh: why does this depend on getting an AMO file server?
> 
> Because we don't want to have a python process locked up serving a file.  File
> servers can do that much more efficiently.

Sorry to butt in here, but is that/could that be part of the WGSI/500 problem we see on preview/next?

Comment 10

[Jeff Balogh (:jbalogh)]

(In reply to comment #9) 
> Sorry to butt in here, but is that/could that be part of the WGSI/500 problem
> we see on preview/next?

No.

Comment 11

[Jeff Balogh (:jbalogh)]

This needs to use https://preview.addons.mozilla.org/files for local files and then we'll be good.

Comment 12

[Jeff Balogh (:jbalogh)]

http://github.com/jbalogh/zamboni/commit/be05588

Comment 13

[Wil Clouser [:clouserw]]

I've been hitting this on PAMO and haven't gotten it to die yet.  QA: As you can expect, this is a pretty big deal so we should test it well.  URLs include stuff like:

 /file/:id/name
 /file/:id/type:attachment
 /latest/1865/type:xpi/platform:5

Comment 14

[Jeff Balogh (:jbalogh)]

Also make sure downloads do the right thing for thunderbird.

Comment 15

[Jeff Balogh (:jbalogh)]

Cleaned up in http://github.com/jbalogh/zamboni/commit/cc058d2

Comment 16

[Wil Clouser [:clouserw]]

loadtest+.  We get anywhere from 80r/s (on /file/ downloads) and 180r/s (on /latest/ downloads).  It looks like we're _averaging_ 2r/s on the live site, so that gives us some buffer space for peak days

Comment 17

[krupa raj[:krupa]]

This is looking good.