Bug 16546 – Problems in JIRA with Safari 3 and downloading .class attachments

• Component: WebKit Misc.
• Status: RESOLVED INVALID

[Michael Tokar]

This problem seems to be two-sided:

1) When uploading an attachment to JIRA with a .class extension using Safari 3, the content-type (as inferred from the HTTP request by JIRA) is set to application/octet-stream. The correct type should be application/java-vm or application/java.

When uploading the same file using Firefox on Linux, the content type is set correctly to application/java-vm, but when using Firefox on Mac, the content-type is set to text/plain (!). Firefox on Windows yields the same result as Safari 3 (application/octet-stream). Internet Explorer 6 yields application/java.

2) This is more important. When downloading the above attachments using Safari 3, any attachment which does not have the "correct" content-type set (application/java or application/java-vm) will become corrupted by Safari 3 when saving it to local disk. That is, the downloaded version will have the same filesize as the original, but the MD5 sums will be different. This can be easily verified:
i. upload a .class file with Safari 3. Observe the content-type of the stored attachment (go to Manage Attachments for the issue)
ii. download the same attachment and compare the MD5 sums of the file you uploaded versus the file you downloaded

We are tracking this as a JIRA issue at the following URL:
http://jira.atlassian.com/browse/JRA-14153

Note however that currently this issue is only visible to Atlassian staff, but we will probably open it up now that we have confirmed it is not a JIRA issue but an issue with Safari 3 / other browsers. Incidentally, the issue also occurs in Confluence.

If you could please keep me posted about the progress of this issue, that would be really helpful.

Thanks,
Michael Tokar [Atlassian]

[David Kilzer (:ddkilzer)]

<rdar://problem/5660089>

[David Kilzer (:ddkilzer)]

Created attachment 18050 [details]
Java source file

Here's a Java source file to compile:

$ javac Test.java

Used the "auto-detect" feature for uploading the file from Mac OS X 10.5.1 (9B18).

Oops..."auto-detect" didn't work so I made it "text/plain".

[David Kilzer (:ddkilzer)]

Created attachment 18051 [details]
Java class file

Here's a Java class file.

Used the "auto-detect" feature for uploading the file from Mac OS X 10.5.1 (9B18).

Compiled with:

$ java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> <rdar://problem/5660089>

This radar covers the .class file corruption issue.

I filed this radar for the desired MIME type issue:
<rdar://problem/5661057>

[David Kilzer (:ddkilzer)]

(In reply to comment #0)
> 2) This is more important. When downloading the above attachments using Safari
> 3, any attachment which does not have the "correct" content-type set
> (application/java or application/java-vm) will become corrupted by Safari 3
> when saving it to local disk. That is, the downloaded version will have the
> same filesize as the original, but the MD5 sums will be different. This can be
> easily verified:
> i. upload a .class file with Safari 3. Observe the content-type of the stored
> attachment (go to Manage Attachments for the issue)
> ii. download the same attachment and compare the MD5 sums of the file you
> uploaded versus the file you downloaded

With my small example Test.class file (Attachment #18051 [details]), I don't see any issues.

Michael, could you try uploading a class file to this bug and downloading it again to see if you can reproduce the issue here?

[Michael Tokar]

Created attachment 18075 [details]
Test attachment

[Michael Tokar]

(In reply to comment #5)
> With my small example Test.class file (Attachment #18051 [details] [edit]), I don't see any
> issues.
> 
> Michael, could you try uploading a class file to this bug and downloading it
> again to see if you can reproduce the issue here?
> 

I uploaded "Test attachment" with the auto-detect content type (which resulted in application/octet-stream).

The MD5 sum before uploading was eb252b88cbc15d4572670ece2e5b5e0f
The MD5 sum after downloading is 489ee94f1b871ddceeb7d60d209d1071

Upload and download was done with Safari 3.0.4 5523.10

[Michael Tokar]

The original JIRA issue is now viewable by all. See URL field for link.

[Alexey Proskuryakov]

(In reply to comment #5)
> With my small example Test.class file (Attachment #18051 [details] [edit]), I don't see any
> issues.

Dave, that's likely because you test on a PowerPC Mac - I can reproduce this problem with both attached .class files on my MBP.

Something below WebKit swaps endianness of downloaded .class files - instead of starting with 0xCAFEBABE, they start with 0xBEBAFECA.

This is clearly a bug - however, it is not in open-source WebKit, but in underlying Apple libraries used for file downloading in Safari. So, I'm closing this bug as INVALID per our process, and it will continue to be tracked in Radar. Thank you very much for reporting this!

[Alexey Proskuryakov]

*** Bug 21069 has been marked as a duplicate of this bug. ***