265684 - ";type=d" survives as part of the directory name in links to individual files

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[bmoeller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921

By RFC 1738, an URL such as
     ftp://ftp.openssl.org/snapshot;type=d
lets the browser know that "snapshot" is a directory.  Mozilla correctly
displays the directory listing, but the hyperlinks to individual files are
wrong and do not work, for example
     ftp://ftp.openssl.org/snapshot;type=d/README
where the link should point simply to
     ftp://ftp.openssl.org/snapshot/README
(the optional ";type=<typecode>" part belongs only at the end of URLs).

(A nice feature would be to automatically displays READMEs over the directory
listing for the ";type=d" form.  This is what at least Netsscape Communicator
4.8 used to do.)

Reproducible: Always
Steps to Reproduce:
1. View ftp://ftp.openssl.org/snapshot;type=d
2. Try any link to an individual file


Actual Results:  
Browser tries to get ftp://ftp.openssl.org/snapshot;type=d/README
(which of course does not exist).

Expected Results:  
Get ftp://ftp.openssl.org/snapshot/README

Comment 1

[benc]

view source doesn't work (seems to display "raw" for working directories) but
view info shows that the links are building the url base from the URL, rather
than just the valid path components.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This sounds like a bug in nsStandardURL... Resolve() should be ignoring the
param.  Darin, any idea what's up here?

Comment 3

[Patrick McManus [:mcmanus]]

should this stay open?

Comment 4

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

This bug, as stated in comment 0 no longer applies.
After bug 682762 we call removeParamsFromPath which cuts off the URL at ;
This means that ftp://ftp.openssl.org/source;type=d/README actually goes to ftp://ftp.openssl.org/source/
Marking as WORKSFORME.