I'm not sure if we reached a conclusion on this, but I don't like a
couple of aspects of the Firefox logic (assuming I understood it
correctly).
The way I would look at it, the browser always has a "current context"
that indicates the current base to use for relative URIs. In the case
where you are launching the browser for the command line, the current
base = $CWD (and, implicitly, file://).
So, you then get the following algorithm:
1) if there is a ':' in the URI, you split the URI into scheme and
scheme-specific part.
2) If there is a scheme:
2.1) If the scheme is a recognized/supported one, dispatch the URL
as you would normally.
2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an
absolute local file URL
2.3) Else, treat this as a syntax error in the URI
3) If there is no scheme:
3.1) If the URI starts with a "/", treat it as a full path relative
to the current context (e.g., current scheme, host and port. If your
current context is a local filesystem, then treat it as a file://
scheme
3.2) If the URI starts with a "\", you're on Windows, and the
context is a local file system point, repeat as above, prepending with
the current drive
3.3) If the URI doesn't start with a "/" or a "\", then, optionally,
check to see if the URI resolves to a valid hostname. This catches the
"chrome.exe www.google.com" use case
3.4) If the URI doesn't resolve to a valid hostname, then interpret
it as a relative URL
I think this is mostly the same as the FF algorithm, except for 3.3. I
agree that trying the "local then remote" logic is probably going to
lead to weird and/or unintended consequences. I could be convinced to
omit 3.3, but I don't see any real risks here. The worst case is that
you'd have to specify "./www.google.com" to open a relative local file
called www.google.com, but that's a pretty obscure corner case.
I wouldn't add the -url switch, since it is actually misleadingly
named (relative URLs are URLs).
-- Dirk
On Mon, Jan 11, 2010 at 2:23 PM, Benjamin Smedberg <bsmedb...@gmail.com> wrote:
> For what it's worth, the way Firefox solves this is:
>
> * Check if the file is an absolute file path
> ** on Windows, X:\... or \\...
> ** on Posix, /...
> * Otherwise, it's a URL relative to the current working directory
> ** So index.html resolves using the URL machinery to
> file:///c:/cwd/index.html
> ** while http://www.google.com resolves to itself
>
> This doesn't deal with the case firefox.exe www.google.com (which would try
> to resolve as a file), but we decided not to care about this case. We do
> have the explicit firefox.exe -url www.google.com which will perform URI
> fixup to guess the correct URL.
>
> --BDS
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
