289646 - local references to files with "&" and ";" in the name report that file is not found.

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P5)

Description

[kmlee]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050319
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050319

For example, if I have the following local file name either in the location bar
or within the web page, Mozilla will report that it is not found.

file:///D:/sites/videohelp/guides.php-guideid=420&howtoselect=1;54.htm#420

However, when I change the ";" to %3b, it works.

Also - with IE, it finds the local file OK. 
If I had only one browser, this would be a critical problem, but I guess I have
to use IE till the bug is fixed.

Also, if this is a remote reference, it works - for example:

http://www.videohelp.com/guides.php?guideid=420&howtoselect=1;54#420


Reproducible: Always

Steps to Reproduce:
1. Go to the http url above, save the page, overriding the default file name to
that of the file:/// above, of course with the appropriate drives and without the #

2. Try to access the local file with the ";" intact in its name
3. 

Actual Results:  
File ... cannot be found.
Please check the location and try again.

Expected Results:  
change the ";" to %3b and get the correct url.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, necko includes the # in the filename for some reason...

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

(fwiw the & in html needs to be escaped as &, although that seems unrelated
to this issue)

Comment 3

[Andreas Otte]

If we break down the http-url it looks like this

http
://
www.videohelp.com
/
guides.php
?guideid=420&howtoselect=1;54
#420

where guides.php is the filename, guideid is part of the query-component until
the # which marks the ref-component. Within the query component and the path the
; has special meaning and must be escaped when part of the filename or something
else. file urls can also have these components (if that makes sense is something
else)

Now what seems to happen is that the query component is saved as part of the
filename with its full glory without the ref-component but including the ; which
is a reserved character inside the path *and* inside the query component. This
changes the semantic of the url, now the ; becomes part of the path, still a
reserved character and everything after the ; gets ignored as part of the path
=> file not found. If escaped everything is fine. It seems to me we do the right
thing here.

Do you really need the query-component as part of the filename?

Comment 4

[Ben Fowler]

See Bug 132649 "Files downloaded from query-string urls get wrong filename', and
several similar reports, but I don't see an exact duplicate.

Comment 5

[benc]

So this is more a problem w/ the way we save the file, not w/ the URL parser, right?

Comment 6

[Hixie (not reading bugmail)]

> the # which marks the ref-component. Within the query component and the path 
> the ; has special meaning

No it doesn't. See RFC 3986.


> file urls can also have these components

No they can't. See RFC 1738.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

ah, yes. comment 3 seems to indeed describe what happens:
js>
x=ios.newURI("file:///D:/sites/videohelp/guides.php-guideid=420&howtoselect=1;54.htm#420",
null, null);
[xpconnect wrapped nsIURI]
js> x.nsIFileURL.file.path
/D:/sites/videohelp/guides.php-guideid=420&howtoselect=1
js> x.path
/D:/sites/videohelp/guides.php-guideid=420&howtoselect=1;54.htm#420
js> x.filePath
/D:/sites/videohelp/guides.php-guideid=420&howtoselect=1

Comment 8

[Andreas Otte]

I was not aware of the new RFC 3986 which obsoletes RFC 2396 on which the
urlparser is still based. Thanks for the hint. Also we might need to handle file
paths differently. Makes sense. I will think about it.

Comment 9

[kmlee]

Hi to all
Thanks for all the hard work put in.

In response to:
> Do you really need the query-component as part of the filename?

You may have guessed that the name put there was from a web "spider", which 
creates the local file name from the url. Again, IE does it OK.

Regards,

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Darin Fisher]

Confirming.  There's work to be done here.

It's unclear to me what "Updates RFC 1738" exactly means in the context of RFC
2396 or RFC 3986.  I'm also not sure to what extent we should or will need to
break RFC 2396 in our efforts to support RFC 3986.

Comment 12

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Works for me. I loaded file:///c:/Users/Valentin/Downloads/test;&.txt