392713 - Linkify dir listing headings

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[Dão Gottwald [:dao]]

This is left over from bug 294800.

Current output:

  <h1>Index of ftp://ftp.mozilla.org/pub/mozilla.org/</h1>

Expected:

  <h1>Index of <a href="ftp://ftp.mozilla.org/">ftp.mozilla.org</a>/
  <a href="ftp://ftp.mozilla.org/pub/">pub</a>/mozilla.org/</h1>

Note that this has already gotten ui-r+.

Michael, you wrote you've been working on bug 294800. Do you have a patch for this?

Comment 2

[Biju]

Alternately for
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/

  <h1>Index of <a 
     href="/"        >ftp.mozilla.org</a>/<a 
     href="../../.." >pub</a>/<a
     href="../.."    >mozilla.org</a>/<a
     href=".."       >firefox</a>/releases/</h1>

will also works.

Comment 3

[Michael Ventnor]

Attachment: Patch

Holy crap, this took me hours to get working right, and even then I feel I could've done a better job. Its a mess, but it works, and thats all that matters, right? :)

Well, I did try to clean it up as much as I could but I would love suggestions.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Um... is most of that just working around resolve() bugs?  Would it make sense to just fix those bugs instead?  Perhaps even write some tests to make sure that resolve() gives the same results as newURI with a base URI and relative path?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Put another way, the jar, file, and EndsWith(..) parts of that patch should all be unnecessary.  The URI code should handle that.  Then you also won't need to muck with the charset stuff as much, especially if you get the encoding from the URI object instead of using the parser encoding, which has everything to do with the data and nothing to do with the URL (which was generally encoded from some totally different document).

Comment 6

[Michael Ventnor]

Maybe the EndsWith part, and only because I can't really think of another way to do that easily, but the file is needed because Resolve("..") doesn't always do as expected with file, especially on Linux, which is why there is a special GetParent function to work for every platform.

The jar is also necessary because we don't want to go past the !/, where the jar file structure begins.

Can you please explain how the URI object can handle that? The reason for all the decoding stuff is so I can unescape %-encoded characters so they won't count as 3 characters when we look for the last /, for example "Documents and Settings" would ruin the link set without it.

Comment 7

[Michael Ventnor]

(In reply to comment #6)
> The jar is also necessary because we don't want to go past the !/, where the
> jar file structure begins.

In addition, from what I've found at least, Resolve("..") on the root directory of a jar file will just resolve to the same folder, so i need that check to break out of the while loop.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Just realized I wasn't cced....

> but the file is needed because Resolve("..") doesn't always
> do as expected with file

Why not?  And again, isn't that something we should fix?  If file URIs need to do GetParent() internally to properly implement Resolve("..") then so be it, but it shouldn't be in this coe.

> The jar is also necessary because we don't want to go past the !/,

Uh.. how would that happen, exactly?

> Can you please explain how the URI object can handle that?

Which?

> for example "Documents and Settings" would ruin the link set without it.

I don't see why.  Details?

> Resolve("..") on the root directory of a jar file will just resolve to the
> same folder

Right.  The way this code _should_ work, imo, is to build up an array of URIs using resolve("..") until you get back the same URI you called resolve() on; at that point you've reached the root.  Once you have this array, you can use either string stuff as you do or nsIURL::getRelativeSpec to get the pieces to display.