Closed Bug 5480 Opened 26 years ago Closed 26 years ago

Bugzilla refuses to accept attachment if it is very very big.

Categories

(Bugzilla :: Attachments & Requests, defect, P3)

x86
Windows 98

Tracking

()

VERIFIED FIXED
Bugzilla old

People

(Reporter: Crysgem, Assigned: terry)

References

Details

Attachments

(5 files)

In attempting to submit/attach a .jpg to an earlier bug report, one encounters one omission, and one blatant flaw. The filetypes listed in the Win32 file browsing dialog box do not include types GIF and JPEG (but does include the bloat-inducing BMP format). Second, for one part, attempting to submit a file as MIME type "Other", where the user is tasked to enter the file type, fails universally, as the system seemingly ignores the input (in this case, image/jpeg)... alongside all other submissions! As, for the second, howsoever one submits this .jpg file, Bugzilla insists on accepting the file as type text/html.
Attached image Wood wallpaper (deleted) —
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
I don't believe I have any way of controlling the filetypes that come up in the Win32 file browser. That does sound like a bug, but one in the browser, not in Bugzilla. I don't understand why you have having trouble getting bugzilla accepting a file as type image/jpeg. I have made such an attachment on this bug as proof that it does indeed work.
Attached image Test (deleted) —
Status: RESOLVED → REOPENED
Does Bugzilla impose a limit on the size of the attached file? I successfully submitted a small (~50 K) JPEG, but files of sizes 200 K, 300 K, and 700 K return what is titled "Software error", followed by the ASCII-ticized contents of the file, just as with my original report... *and* the type is smashed to text/html. (A file of so great a size is necessary for the screenshot it encodes)
Status: REOPENED → ASSIGNED
Summary: Bugzilla refuses to accept attachment except as type "text/html" → Bugzilla refuses to accept attachment if it is very very big.
Resolution: WORKSFORME → ---
Yeesh. OK. I have changed the summary of this bug to reflect the real problem. It looks like the perl-to-mysql connection gets upset with the amount of data being shoved through it.
I just realized that my bug 6952 is a duplicate of this. I will therefore mark it as such (after all, this one beat me to it, I just didn't realize it), but I think I have more info for you in 6952... In particular, I believe the current limit on attachment size is 64k. I do believe there are legitimate reasons you might want to limit the size of the attachments, in particular so as to prevent spamming, overloading, and general abuse of the database, but could this limitation at least be documented?
*** Bug 6952 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
So, it turns out that the maximum size of an attachment is limitted by the maximum size of a packet that mysqld is prepared to accept. By default, that packet size is 64K. I just reconfigured mine to be 1024K, by adding this to the command line that starts safe_mysqld from /etc/init.d: -O max_allowed_packet=1M
Attached image Testing... (deleted) —
Attached image Testing a much larger one... (deleted) —
Status: RESOLVED → VERIFIED
Yep, I'd say it's fixed! This will really help me when it comes to attaching screenshots. Thanks!! I'll mark it verified, since I've seen it too, with my own eyes.
Unsetting target milestone so we can delete the old (inappropriate) Mozilla target milestones from Webtools.
Target Milestone: M7 → ---
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
QA Contact: matty
Target Milestone: --- → Bugzilla old
Version: other → unspecified
Component: Bugzilla-General → attachment and request management
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: