missing slash in file: URL parses incorrectly

VERIFIED FIXED in M14

Status

()

Core
Networking
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Warren Harris, Assigned: Andreas Otte)

Tracking

Trunk
All
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], URL)

(Reporter)

Description

18 years ago
If you pass the following string to nsStdURL:
  file://y|mozilla/makefile.win
rather than:
  file://y|/mozilla/makefile.win

nsStdURL parses the hostname as "y|mozilla" and makes the path be
"/makefile.win" whereas it should treat the entire string
"y|mozilla/makefile.win" as the path.
(Reporter)

Updated

18 years ago
Blocks: 13449
Target Milestone: M12
(Assignee)

Comment 1

18 years ago
We really need to agree on what to do with this wrong URIs:

1. Make Parse() in nsStdURL.cpp better (needs protocol specific code)

2. Check in the File-Protocol-Handler if there is a host after parsing, and when
there is, give a MALFORMED_URI error
(Reporter)

Comment 2

18 years ago
This URL parsing stuff has been so error prone (I count 29 (!) bugs so far on
this stuff). Maybe the right solution here is to split out nsStdURL into two
classes: nsFileURL and nsNetURL. Then they can have protocol-specific parsing
rules.

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 3

18 years ago
I totally agree that we should pull file specific parsing out into its own.
(Assignee)

Comment 4

18 years ago
I think there a two classes here: URIs with host and without

Comment 5

18 years ago
Moving Assignee from gagan to warren since he is away.
(Assignee)

Comment 6

18 years ago
I tried this and I have now three URL classes nsStdURL (like before, but with a
rewritten Parser), nsHostURL (when you are sure you have a URL with a host) and
nsNoHostURL (when there is no host in the URL).

The ProtocolHandler (http, ftp) are using nsHostURL, file is using nsNoHostURL.
This way it is possible to parse certain malformed URLs right according to the
requested protocol.
(Reporter)

Comment 7

18 years ago
I think we determined that the bug here was using 2 slashes after file: instead
of 3. 3 works.
(Reporter)

Updated

18 years ago
Target Milestone: M12 → M13

Comment 8

18 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 9

18 years ago
I got bit by this bug when I migrated profiles and my 4.x home page (which is a
local file) would no longer display since it was saved as file://e|/...
(Assignee)

Updated

18 years ago
Assignee: warren → andreas.otte
(Assignee)

Comment 10

18 years ago
assigning this bug to me per Warrens request
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 11

18 years ago
Andreas: This was supposed to be fixed by your changes that I just checked in,
but when I tried to fetch the file URL, the browser started spinning in the
parser, steadly eating up all of available memory. Looks like one for harishd,
perhaps, but you should verify.
(Reporter)

Comment 12

18 years ago
P.S. If you see this problem too, we probably should open a new bug on that.
(Assignee)

Updated

18 years ago
Target Milestone: M13 → M14
(Assignee)

Comment 13

18 years ago
This will not make it into M13

Comment 14

18 years ago
I also noticed the same crash as warren with 2000011608 win95, but for URL like
file:///c  or file:///c|  or file:///foobar

(The last one is what you get if you download a file from the net that uses
absolute paths for HREF, and you open the file from the disk in the browser).
(Reporter)

Updated

18 years ago
Keywords: beta1

Updated

18 years ago
Whiteboard: [PDT+]

Comment 15

18 years ago
Putting on PDT+ radar for beta1.
(Assignee)

Comment 16

18 years ago
This one should be fixed now. Two slashes are expanded to three, I see no crash.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
verified:
Linux 2000020708
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.