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
OS: Linux → All
Version: 1.4 Branch → Trunk
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This sounds like a bug in nsStandardURL... Resolve() should be ignoring the param. Darin, any idea what's up here?
Assignee: dougt → darin
Component: Networking: FTP → Networking
should this stay open?
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.