83442 - HTTP upload chops off firt 5 bytes of jpg

Status: VERIFIED DUPLICATE of bug 83065

(Core :: DOM: Core & HTML, defect)

Description

[Jeremy Hoyland]

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

[James Green]

--> Form Submission

Comment 2

[James Green]

Reassigning too this time.

Comment 3

[rods (gone)]

reassigning

Comment 4

[timeless]

reporter: we need your buildid or cvs build date.

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

Comment 5

[Grey Hodge (jX)]

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

[Grey Hodge (jX)]

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

[Grey Hodge (jX)]

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.

Comment 8

[Jeremy Hoyland]

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

Comment 9

[Eric Pollmann]

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.

Comment 10

[Eric Pollmann]

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)

Comment 11

[Eric Pollmann]

Attachment: working test case

Comment 12

[Eric Pollmann]

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!

Comment 13

[Grey Hodge (jX)]

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

[Grey Hodge (jX)]

Reopening as per previous comments

Comment 15

[Eric Pollmann]

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...

Comment 16

[Eric Pollmann]

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 ***

Comment 17

[Grey Hodge (jX)]

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

[Vladimir Ermakov]

verifying duplicate

Comment 19

[Eric Pollmann]

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.

Comment 20

[Eric Pollmann]

*** This bug has been marked as a duplicate of 83065 ***

Comment 21

[Vladimir Ermakov]

verifying duplicate