Closed Bug 346171 Opened 19 years ago Closed 19 years ago

Need to be able to upload dictionaries larger than 1.5MB limit

Categories

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

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: kairo, Assigned: oremj)

Details

Currently (though it's not written anywhere on the pages, from what I see), we seem to have the upload limit for extensions set to 1.5 MB - at least bug 258442 comment 4 suggests that. As we're now uploading dictionaries for Gecko-1.8.1-based products to AMO, I ran into a problem with that, as the German dictionary extension is ~2.5 MB (the de-DE.dic is almost 10 MB in its uncompressed state). Because of that, we need to increase the extension size limit - at least if we want to have a current German dictionary on AMO.
Resummarizing to describe the real problem, not one possible solution.
Severity: normal → major
Flags: blocking-firefox2+
Summary: Need bigger upload limit for extensions → Need to be able to upload dictionaries larger than 1.5MB limit
Could someone take a look at what the upload limit is on Iguana, and increase it to a higher value (maybe 10MB, or something arbitrarily larger)?
Assignee: nobody → server-ops
Component: Developer Pages → Server Operations
Flags: blocking-firefox2+
Product: Update → mozilla.org
Version: unspecified → other
The upload limit is most likely set in the php.ini file in /etc/php4/ -- see: http://php.osuosl.org/manual/en/ini.core.php#ini.upload-max-filesize If it's already larger than 1.5MB, then we'd have to look at the total memory limit, possibly -- since I imagine the .xpi is being inflated to read the install.rdf, and that could be pretty expensive.
Is this limit in place to protect against something specifically, or just something that happened to be around in the PHP config?
PHP sets conservative defaults (2M I think) - in my experience anytime an app deals with uploads the limit is eventually hit by someone. Usually it's a huge PDF, though, not a German dictionary. :) I don't think having a limit ~10M would hurt anything or be any sort of risk.
Assignee: server-ops → oremj
This should be fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Hrm, I still get the empty page described in bug 346168 when trying to upload the German dictionary...
OK, tried a second time today, in case my try yesterday would have been too early after the change, but it failed again a few minutes ago. Not fixed for me --> REOPEN. I give you the .xpi file I'm trying so that you're able to test yourself...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
How big is this file uncompressed?
As I said in comment 0, the .dic file is almost 10 MB, and the rest of the .xpi (.aff and install.*) is almost nothing, so all the content of the .xpi is about the same, 9.6 MB is what my archiver app shows.
Sorry, skimmed the comments the first time through. Anyways, I bumped the limits a little more, could you try this again. I'm not seeing any errors in the logs that were caused by this. Maybe it was just timing out? Thanks.
I still can't get it to work, but it's very much possible you don't immediately see an error, given that I get the same emtpy page as if I would have left the file input field blank. I've temporarily uploaded the dictionary xpi to http://www.hg23.at/~robert/mozilla/de-DE-dictionary.xpi so you people can test adding it...
Mate, you've got an extra directory in your add-on. Get rid of the global directory :)
Argh, thanks. It works now, but not getting any error messages is not very helpful :( That's bug 346168 though...
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
No worries mate. Verifying as I uploaded a ~2.4MB file to test this :)
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.