678262 - Unable to download from the add-on packager

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[krupa raj[:krupa]]

steps to reproduce:
1. Create an add-on at https://addons.allizom.org/en-US/developers/addon/package/
2. Try to download the .xpi

expected behavior:
Download is successful.

actual behavior:
https://addons.allizom.org/en-US/developers/addon/package/download/4473cfab53eb466ca959eb08397c55dc loads

[11:32:26.199] GET https://addons.allizom.org/en-US/developers/addon/package/download/4473cfab53eb466ca959eb08397c55dc [HTTP/1.1 404 Not Found 234ms]

Comment 1

[Daniel Buchner [:dbuc]]

Moving to applicable component

Comment 2

[Wil Clouser [:clouserw]]

Maybe this has something to do with the apache rewrites and /z/?  Even when I add a /z/ to the download URL I still get a 404 though.

Basta: what do you need to debug this?

Comment 3

[Matt Basta [:basta]]

This looks like a configuration problem. When I go to download a package, I get this error:

The requested URL /z/en-US/developers/addon/package/download/842f2fc53ccc4443a11804837cfc38f3 was not found on this server.

If I change the hash to another valid hash (that hasn't been generated), the proper AMO 404 page shows.

During development, I'd had trouble with HttpResponseSendFile, which wasn't sending the file down because of XSENDFILE in settings.py. I'd bet this is why the problem doesn't seem to exist on prod.

Comment 4

[Wil Clouser [:clouserw]]

What configuration specifically?  You're saying XSENDFILE isn't correct on preview?

Comment 5

[Matt Basta [:basta]]

I really don't know. I imagine the issue is at least somewhat related, since it appears to come from that same trouble point. Because a legitimate 404 is raised when an unknown hash is given in the URL, it means that the pattern in urls.py is being matched and the package_addon_download view is being called. The code is very straightforward:

https://github.com/mattbasta/zamboni/blob/addon-packager/apps/devhub/views.py#L557

The Http404 is probably what is being hit when an unknown hash is inserted, which makes sense. When a valid hash (i.e.: the hash in the actual download link) is given, the only other code that's being run is the HttpResponseSendFile bit. Perhaps I'm not using that right?

Comment 6

[Wil Clouser [:clouserw]]

Fixed!

XSendFile uses a whitelist of directories it will serve from which is specified in the vhost.  Added this directory and it works now.

Comment 7

[krupa raj[:krupa]]

works now