99789 - when saving a file some characters from the name are missing

Status: VERIFIED DUPLICATE of bug 136831

(Core Graveyard :: File Handling, defect)

Description

[Tim Kirchens]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

When a file has been selected to be downloaded, and mozilla is asking where to
save the file, the name field is missing the first couple (usually 2) characters
of the file name.  This has happened to more than just one file on one server.

Reproducible: Always
Steps to Reproduce:
1.Goto www.fileplanet.com download a file. Notice the file name when saving is
missing the first couple of characters.
2.
3.

Actual Results:  Always missing the first couple of characters from file name

Expected Results:  Used the exact file name from the server.

Comment 1

[Ashley Bischoff (blog at handcoding.com)]

WFM 2001091403 on Win2k. 

New URL:
http://lcix.tucows.com/mmedia/adnload/196134_76275.html
(since no url was previously supplied, and I didn't have a "GameSpy ID" to login
to fileplanet)

Reporter: You may wish to try a fresh profile. You can create/manage profiles
with "mozilla.exe -profilemanager".

Comment 2

[R.K.Aa.]

In a similar bug, the problem wasn't missing characters, but that they didn't
fully display. Selecting the text and dragging mouse to the left revealed that
the leading characters were initially positioned wrong, out of view.

Reporter: Can you try this and tell what happens?
If there are still are no characters there: What happens if you save the file?
Is the filename truncated as well?

Comment 3

[Tim Kirchens]

If i try and drag the mouse, as you say, it doesn't scroll or anything.  the
characters are not there.  I have noticed that if i make a new profile, it seems
to correct the problem, however, if i switch to the modern profile, it causes
this problem to reappear.  very odd.

Comment 4

[timeless]

.

Comment 5

[R.K.Aa.]

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

Comment 6

[R.K.Aa.]

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

Comment 7

[R.K.Aa.]

confirming based on dups

Comment 8

[Marcus Münch]

In some nightly builds this problem seemed to be fixed (I checked this at the
end of October and the beginning of November, and it worked fine, but with the
0.96 milestone the error is still there.

Comment 9

[jlarsen]

still seeing in 2001122603 trunk

Comment 10

[R.K.Aa.]

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

Comment 11

[R.K.Aa.]

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

Comment 12

[Tim]

Here is a reproducible test case and an explanation.

The URL
http://xferla4.fileplanet.com/^1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3
(or a slight variation of it) is included on the page mentioned above. During
the request, it is translated into ...et.com/%5E176..., since "^" is defined as
an "unwise" character that needs encoding by RFC 2396 (the URL specification
ftp://ftp.isi.edu/in-notes/rfc2396.txt) in section 2.4.3.  The server accepts
the request for the file but includes a slightly truncated name in a
Content-Disposition header (see below).

I tested and confirmed this on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020622
built from CVS trunk (last updated yesterday, 2002-06-27 around 8pm)

The person who reported it initially on #mozilla has:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020622
Build ID: 2002062213


A conversation recorded with WGET and two recorded with TELNET follow:
Wget (entered on the command line _un_encoded):
http://xferla4.fileplanet.com/%5E1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3
           => `/dev/null'
Resolving xferla4.fileplanet.com... done.
Connecting to xferla4.fileplanet.com[66.28.8.232]:80... connected.
HTTP request sent, awaiting response... 
 1 HTTP/1.1 200 OK
 2 Date: Fri, 28 Jun 2002 03:50:00 GMT
 3 Server: GameSpy-XFS/1.0
 4 Connection: close
 5 Content-Type: application/octet-stream
 6 Accept-Ranges: bytes
 7 Content-Disposition: file; filename=art_tvrb.mp3
 8 Last-Modified: Thu, 24 May 2001 00:27:36 GMT
 9 Content-Length: 5057840


Telnet Encoded:
telnet xferla4.fileplanet.com 80
Trying 66.28.8.232...
[...]
HEAD /%5E1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3 HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 28 Jun 2002 03:16:59 GMT
Server: GameSpy-XFS/1.0
Connection: close
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Disposition: file; filename=art_tvrb.mp3
Last-Modified: Thu, 24 May 2001 00:27:36 GMT
Content-Length: 5057840

Telnet Unencoded (illegal according to the RFC):
HEAD /^1763091103/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3 HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 28 Jun 2002 03:18:14 GMT
Server: GameSpy-XFS/1.0
Connection: close
Content-Type: audio/mpeg
Accept-Ranges: bytes
Content-Disposition: file; filename=heart_tvrb.mp3
Last-Modified: Thu, 24 May 2001 00:27:36 GMT
Content-Length: 5057840

Note that, while I can't make these decisions, I'm recommending:
-> evang, US general

Comment 13

[Tim]

Oops, forgot to paste in some extra info (I cut/pasted it from a bug I almost filed)

The page to find the link I mentioned is
http://www.fileplanet.com/dl/dl.asp?/planetdreamcast/sonic/music/sa1/heart_tvrb.mp3

Comment 14

[Grey Hodge (jX)]

Working with Tim but indedpendently, we came to a similar conclusion. I tend to
agree that we're looking at a problem with the URLs.

Comment 15

[Tim]

Moving to networking.  See comment 12 for why skinnability has nothing to do
with it (removing modern keyword for same reason). My personal opinion is still
tech evang, but we'll see where it goes.

Comment 16

[benc]

-> file handling:

can someone please add an example to the URL field + state the expected and
observed filenames?

Comment 17

[benc]

argh

Comment 18

[Tim]

I'd provide a URL, but they seem to expire rather quickly, and I only managed to
do my testing when someone in #mozilla had an account and provided me with a
(then-working) direct link.

From my description in comment 12, the expected filename is heart_tvrb.mp3 and
the actual is art_tvrb.mp3.

The cause of this difference is that the *server* is sending the wrong filename
in the Content-Disposition header when the "^" at the beginning of the URL is
encoded (and only when it is encoded).  Presumably, it works in IE because they
ignore the filename (if not the whole header) given by Content-Disposition.

I believe the proper resolution would be to contact the server vendor and tell
them to read RFC 2396 (section 2.4.3) to get encoding/decoding correct.

An alternate resolution would be to ignore filenames that are specified in
Content-Disposition in certain cases (or altogether), but I wouldn't personally
stand behind that recommendation.

Comment 19

[benc]

(finally changing ownership. sorry for spam of my jet-lagged failures from before.)

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Sébastien Delahaye]

v.