108417 - uri to access home (resource://home/ ?)

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[James Green]

This idea comes from a friend.

Type in home://foo.txt in the url bar, and Mozilla should load foo.txt from the user's home directory if set.

Home directory of unix users is normally the bash expression ~/.

There's possibly an RFC for these things, I'm not sure. It would be nice, but it's not something we're seriously lacking. This could also equate to equivalents on other platforms and OSes.

Comments?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Just a note that 

nsCOMPtr<nsIFile> homedir;
NS_GetSpecialDirectory(NS_OS_HOME_DIR, getter_AddRefs(homeDir));

will get one the homedir.  So we should not even have to do the ~/ business.  We
could just map home:// urls to file:// urls by getting this nsIFile and using
appendUnicode() to append the stuff coming after the //.

Comment 2

[Christopher Hoess (gone)]

Is the home directory adequately defined on non-Unix platforms to do this? Also,
per RFC 2717, invented URL schemes should really be in an "alternative tree",
i.e., moz-home://, although we already break this rule with chrome:// and
probably view-source: (javascript: being a widespread misfeature). Maybe we
should hold off and look for an alternative to further polluting the IETF URL
scheme namespace.

Comment 3

[Dan Tobias]

It seems a little too system-specific to me; many OSs have no concept of a user
home directory.

Also, the "//" does not belong in the syntax for such a URL scheme, as it's
intended to precede a hostname.  "home:" would have no use for a hostname, as
it's only meaningful on the local host, so simply "home:foo.txt" would be more
sensible.  If for consistency with other schemes you need a place for a hostname
to reside (even if it's null), you should do it like the file: scheme, which
works like "file:///pathname", with three slashes indicating a null hostname
between the second and third slash (alternatively, "file://localhost/pathname"
works too).

It's a common superstition that all URL schemes need to have the double slash
after the colon, but in fact there are a number of schemes that don't have this
(e.g., "mailto").  Where no hostname is called for, no double slash is needed.

Comment 4

[Christopher Hoess (gone)]

From RFC 2718: "Double slashes are used ONLY when the syntax of the URL's
<scheme-specific-part> contains a hierarchical structure as described in RFC
2396." So I think // is correct in this case; but I stand by my previous comment
that I don't think we should be unleashing more URL schemes without registration.

Comment 5

[sairuh (rarely reading bugmail)]

dunno if pchen's the right person. jag? pls punt as needed.

Comment 6

[jag (Peter Annema)]

I would think what we really want is support for:

file://~/foo.txt

I'd personally recommend WONTFIX on the home:[//] thing.

Comment 7

[timeless]

wouldn't it be file:///~/ not file://~/ ?

home:// is way too specific for something as general as a protocol, we already
have resource: and a few others one of which could easily be modified to add
support for some understanding of ~ if it doesn't already.

Comment 8

[jag (Peter Annema)]

file:///            points to my root directory
file:///home/jag/   points to my home directory
file://~/           also points to my home directory
file:///~/          points to the directory ~ in my root directory

Except of course the 3rd one doesn't work yet :-)

Comment 9

[Bradley Baetz (:bbaetz)]

That would be because the third one is invalid

On linux, open("~/foo") resolves to something meaningful, which is why this
works. We probably get the parent dir wrong, though.

Comment 10

[timeless]

ok, time to ask for the resource: url which might do the right thing, since
clearly file: isn't going to.

Comment 11

[jag (Peter Annema)]

bbaetz, could you explain your comment?

Comment 12

[jag (Peter Annema)]

timeless: resource:/// takes me to my mozilla binary dir (the title shows
"file:///home/jag/mozbin/"), there should be no way to get to your home dir from
there, IMO.

Comment 13

[Bradley Baetz (:bbaetz)]

jag: err, ok, I'll rephrase that. Its not invalid, its just not going to do what
you expect.

What it should do (but doesn't), is that:

file:// - hierarchical scheme (file)
file://~/ - hierarchical scheme (file) with hostname (~) and path (/)

Theres a bug on have file://hostname/ open a unc path on windows. Maybe we could
do this, I guess, on unix. I just don't see why we should bother.

Whats the point of this, anyway?

Comment 14

[Darin Fisher]

it would be trivial to add support for something like:

resource://home/foo.txt

see nsResProtocolHandler.cpp

Comment 15

[Bradley Baetz (:bbaetz)]

Yes, but why bother?

And remember all the security places which differentiate between file and resource.

Comment 16

[jag (Peter Annema)]

Where "home" would be some special kind of |host| for the resource protocol?

Do we really want that? I thought part of the resource protocol was to have
limited access (but maybe I'm just high :-) )

Comment 17

[jag (Peter Annema)]

-> networking

Comment 18

[Daniel Veditz [:dveditz]]

resource: is not limited, it is as powerful as file:/// and simply makes it
easier to find things without having to know the full path as required by
file:///. In that sense it is *more* powerful than file:

resource://profile/blah would be quite worth adding given all the problems we
have with full paths scattered in the profile data, but I imagine the people who
invented profile directory salting won't like that idea much.

Comment 19

[timeless]

i'd imagine the people who invented profile directory salting wouldn't like the
idea of exposing ~ either.  esp say ~/.ssh/identity

Comment 20

[Mitchell Stoltz (not reading bugmail)]

Exposing to whom? It's true that these resource: shortcuts may make certain
attacks easier, as long as pages from the web can't use resource: URLs
(currently true), we should be OK. We're not talking about allowing web content
to use resource://home/* are we?

Comment 21

[benc]

My preference would be to not create a new URL scheme, unless it has
multi-platform usage and is registered with IANA. We have enough mozilla-schemes
that are on my hit list (I have this strange delusion that someday we will
register everything in an RFC...)

What is needed is native file path support. Most people in Linux care about
three spots: home page pref, location|URL and launching from line command. We
have various discussions about all these areas. My feeling is that there should
be a pref that does a "treat as file path first" in the UI. 

re: bash, I have heard that different shells have different expressions. The
solution (to me), would be to see if there is a way to call a shell to find
resolve the path. Mozilla could call the shell specified by the user, otherwise
we have to start hard-coding multiple shell conventions, which sounds like a
wild goose chase.

Comment 22

[Daniel Veditz [:dveditz]]

mitch: webscript aren't supposed to be able to get data out of a file: url
either, yet we salt the profile directory just in case they find a way to access
these URLs. A resource URL that takes you right to ths profile would make the
salting ineffective as a backup security measure.

ben: I don't think anyone is seriously contemplating implementing a "protocol"
as requested, this "home" and "profile" functionality--should we choose to
implement it--could happily live as part of the "host" mechanism already
supported by the existing resource: scheme.

Comment 23

[Darin Fisher]

then i think resource://profile/ should be WONTFIX, but resource://home/ is
probably a decent addition (perhaps only XP_UNIX though).

Comment 24

[timeless]

resource://profile/ would help us fix the bugs about profiles not being movable.

Comment 25

[Akkana Peck]

See bug 12911 for more discussion about why resource:/profile would be useful. 
I'm not sure what the plan currently is for that bug (implement
resource:/profile, or switch to using relative paths?)

Comment 26

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.