Closed Bug 108417 Opened 23 years ago Closed 9 years ago

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

Categories

(Core :: Networking, enhancement)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: jg, Unassigned)

Details

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?
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 //.
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.
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.

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.
dunno if pchen's the right person. jag? pls punt as needed.
Assignee: pchen → jaggernaut
I would think what we really want is support for:

file://~/foo.txt

I'd personally recommend WONTFIX on the home:[//] thing.
Target Milestone: --- → Future
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.
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 :-)
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.
ok, time to ask for the resource: url which might do the right thing, since
clearly file: isn't going to.
bbaetz, could you explain your comment?
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.
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?
it would be trivial to add support for something like:

resource://home/foo.txt

see nsResProtocolHandler.cpp
Yes, but why bother?

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


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 :-) )
-> networking
Assignee: jaggernaut → neeti
Component: XP Apps → Networking
QA Contact: sairuh → benc
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.
i'd imagine the people who invented profile directory salting wouldn't like the
idea of exposing ~ either.  esp say ~/.ssh/identity
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?
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.
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.
then i think resource://profile/ should be WONTFIX, but resource://home/ is
probably a decent addition (perhaps only XP_UNIX though).
resource://profile/ would help us fix the bugs about profiles not being movable.
Summary: [RFE] Implement home:// uri (for home directory shortcuts) → [RFE] uri to access home (resource://home/ ?)
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?)
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
Summary: [RFE] uri to access home (resource://home/ ?) → uri to access home (resource://home/ ?)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.