HTTP upload chops off firt 5 bytes of jpg

VERIFIED DUPLICATE of bug 83065

Status

()

Core
HTML: Form Submission
VERIFIED DUPLICATE of bug 83065
17 years ago
17 years ago

People

(Reporter: Jeremy Hoyland, Assigned: Eric Pollmann)

Tracking

Trunk
mozilla0.9.2
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Uploaded Images corrupted when they arrive on server, ls -l reports that they
are 5bytes smaller than the original, ImageMagic says the header is corrupt.
This problem doesn't occur with IE or Netscape 4.x

(No URL as it's behind a firewall and you have to register)

Comment 1

17 years ago
--> Form Submission
Component: Browser-General → Form Submission

Comment 2

17 years ago
Reassigning too this time.
Assignee: asa → rods
QA Contact: doronr → vladimire

Comment 3

17 years ago
reassigning
Assignee: rods → pollmann

Comment 4

17 years ago
reporter: we need your buildid or cvs build date.

also does it happen for gif,txt,html,gz

Comment 5

17 years ago
I just noticed this too. It's real. Moz hbrks the JPG on uploading. I found this 
out via uploading to Yahoo. NS4.77 works, IE works, Moz build ID 2001060308. 
Win32 build, BTW.

Comment 6

17 years ago
Ack, sorry for the spam. HTML, TXT work ok, GIFs die too, GZips and ZIPs are ok, 
PDFs work, I think it's just graphics. No PNG's handy to test on them though...

Comment 7

17 years ago
More, new information. I don't see Mozilla chopping off the first 5 bytes, I see 
it ADDING 2 bytes to the beginning. Specifically ASCII characters 0D and 0A in 
hex, or 014 and 011 in decimal. This is on JPGs and GIFs.
(Reporter)

Comment 8

17 years ago
Don't know whether this helps,Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; rv:0.9) Gecko/20010505It gets more interesting..Original                               -rw-r--r--    1 jeremyh  imagenet   790175 Jun  5 15:28 analog-5 .gz-rw-r--r--    1 jeremyh  imagenet    13242 Jun  5 15:29 chinese.gif-rw-r--r--    1 jeremyh  imagenet     9251 Jun  5 15:30 dbx.doc-rw-r--r--    1 jeremyh  imagenet    93380 Jun  5 15:30 html .bz2Uploaded(& down again)790140 May 22 15:30 analog-5.01.tar.gz13207 Apr 20 17:03 chinese.gif9251 Jun  5 15:30 dbx.doc 3380 Jun  5 15:30 html .bz2 So .bz2 and .doc OK, .gz differnet size (but gunzip doesn't complain), chinese2.gif corrupted and won't display.Keep up the good work,Jeremy
(Assignee)

Comment 9

17 years ago
Confirming bug per comments.  Sounds bad, but JPG is a lossy compression format,
so this should be expected.  ;)  See also bug 83065 and bug 82260.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.2
(Assignee)

Comment 10

17 years ago
Can someone provide a test url were this problem is reproducible?  In the
meantime, I'll try to cook up one of my own (though all of my previous examples
work just fine)
(Assignee)

Comment 11

17 years ago
Created attachment 38323 [details]
working test case
(Assignee)

Comment 12

17 years ago
This works for me with today's build.  To verify:

1) Open the attachment above labeled "working test case"
2) Click on the "Browse..." button and select an image to upload.
   (I saved ant.jpg from bugzilla.mozilla.org's main page locally and used that)
3) Click on the Submit button.
4) On the resulting page, click on the link labeled "Click here to view image"
5) Right click on the resulting image (should be the one you uploaded), and
select Save Image, then save the image locally.
6) Compare the file sizes, and if possible, run diff to verify that the file you
uploaded is the same as the file recieved.

Here's what I got:

pollmann PC609916(9):/c/WINNT/Profiles/pollmann/Desktop> ls -la *ant.jpg
-rw-r--r--   1 administ None         8474 Jun 13 15:54 ant.jpg
-rw-r--r--   1 administ None         8474 Jun 13 16:09 echo_output_ant.jpg
pollmann PC609916(10):/c/WINNT/Profiles/pollmann/Desktop> diff ant.jpg echo_
output_ant.jpg

Marking this one worksforme unless someone attaches a test case that does not
work as expected.  Thanks!
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 13

17 years ago
This needs reopened. I am including a set of files to compare, and a means of
reproducing.

First, go here to see examples:
http://us.geocities.com/testcase83442/

Now, to test it for yourself, go here:
http://geocities.yahoo.com/ and login as testcase83442 with a password as testcase

Please do not abuse this login or upload kiddie porn or delete everything. You
are not funny if you do, nor cool, or 31337. It will not get you chicks, or the
admiration of your peers. I will simply create a new account, and only give out
the logins personally by email.

Now, upload a jpg via the Upload Manager. Yahoo will tell you the file is
invalid. Rename the file to .zip or another extension, upload it, then rename it
back if you please. Upload an identical copy with Netscpae 4.x or IE. Compare
file sizes. Save the links, and compare the binary data. You will see that 
Mozilla has added 2 bytes to each file. When Yahoo goes to verify the files as
.jpg files, it sees them as invalid due to a corrupt header. To get them there I
had to upload them as ZIPs, then rename them to their current size.

Comment 14

17 years ago
Reopening as per previous comments
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 15

17 years ago
Oh, the Geocities filemanager!  This is a dup of bug 85577 then.  I looked at
your two samples, which helped narrow down the problem some more, thanks!  The
extra characters are x0Ax0D or \r\n, so either we are sending an extra CRLF, or
the Geocities parser is getting confused by our extra headers (See bug 83065 -
we are also confusing the PHP upload parser).

Accepting, and looking into this, as it appears Geocities is not using PHP after
all...
Status: REOPENED → ASSIGNED
(Assignee)

Comment 16

17 years ago
This is fixed by the patch on bug 44464.  That means it is caused by the
Content-Transfer-Encoding header we added in 0.9.1.  Marking dup.  The patch
makes this header controllable by a pref and defaults to not sending it (making
us backwards compatible with Nav 4.x and IE.

*** This bug has been marked as a duplicate of 44464 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 17

17 years ago
Right about what characters it's adding. I mentioned that on 2001-06-05 06:53. 
As for dupe, ok. Glad I could provide good examples, and a testbed for you. And 
just to clarify, when you say "This is fixed by the patch on bug 44464," does 
that mean that this bug is fixed or a fix is immenent? I ask because that bug is 
still open and assigned. Either way, it's a dupe, yeah, so I'll leave my mitts 
off it this time. :)

Comment 18

17 years ago
verifying duplicate
Status: RESOLVED → VERIFIED
(Assignee)

Comment 19

17 years ago
That "fixed by patch" comment meant a fix was available, but not yet checked in.
 :-/  Well, now that I went and marked this a dup of 44464, I'm reconsidering. 
I think that we might be confusing the issue by marking a bug caused by the new
Transfer-Encoding header as a dup of a bug titled "Support uploading multiple
files".  Changing bug I marked this a dup of to be bug 83065 (that bug covers
corruption caused by the same header).  I'll also put a more targetted, specific
fix on that bug report.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 20

17 years ago

*** This bug has been marked as a duplicate of 83065 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 21

17 years ago
verifying duplicate
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.