102603 - file: "?query" is ignored, rather than treated as part of filename

Status: RESOLVED INVALID

(Core :: Networking: File, defect)

Description

[benc]

STEPS:

1- Access URL provided in URL field.

OBSERVED:
/etc/host file is viewed.

EXPECTED:
Unless /etc/hosts?query file exists, no file will display.

COMMENTS:
"?" is reserved, but the BNF in RFC 1738 permits it in the fsegment of an fpath.

My feeling is that this is probably a legal URL. If it is not, hex escaping the
"?" is probably correct, and my URL is invalid.

Comment 1

[Bradley Baetz (:bbaetz)]

Also see bug 59002. I think that our url parser just needs to be different for
file:///, or the fixup we do on urls needs to be modified.

Comment 2

[benc]

+mozilla 1.0 - real problem w/ files vs. file: URLs

Comment 3

[Andreas Otte]

RFC 2396 (which updates 1738) makes ? a reserved character in the path segment,
nsStdEscape provides for escaping of ? in filenames (it marks the query), my
guess is that if the ? is part of the filename it must be escaped to do what is
intended.

Comment 4

[Andreas Otte]

Of course, if everybody is sure that there can't be a query part with file-urls
we could patch an existing query part (as defined by the parser) to the filename
before converting the url to a file.

Comment 5

[benc]

I've made this a testcase.

Comment 6

[benc]

I think this is where someone attempted to make the hierarchical URI syntax more
consistent for http, file and ftp, but sort of neglected to think about the
practical aspects of the format.

RFC 1808 has an intersting comment:

   NOTE: Section 5 of RFC 1738 specifies that the question-mark
         character ("?") is allowed in an ftp or file path segment.
         However, this is not true in practice and is believed to be an
         error in the RFC.  

(this is what happens when you finally get time to read ALL the RFC's, instead
of stopping at 1738).

Comment 7

[benc]

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

Comment 8

[Kevin Brosnan]

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

Comment 9

[benc]

RESOLVED/INVALID:

necko behaves correctly, I just never had time to really think about this after people were kind enough to point RFC 2396.

When I wrote the bug, I was convinced that a file URL w/ a query was invalid, but I think there are weird things that still can use that parameter. More importantly, the URL syntax is clearly defined, I just didn't compose the URL correctly for my test file.

Comment 10

[Kevin Brosnan]

Resolving invalid per comment 9. I am assuming ben intended to make the change. If I am incorrect reopen the bug.