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]
Moving to applicable component
Assignee: mbasta → nobody
Component: Add-on Builder → Developer Pages
QA Contact: add-on-builder → developers
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?
Assignee: nobody → mbasta
Target Milestone: 6.2.2 → 6.2.1
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.
What configuration specifically? You're saying XSENDFILE isn't correct on preview?
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?
Fixed! XSendFile uses a whitelist of directories it will serve from which is specified in the vhost. Added this directory and it works now.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.