On Mon, Jan 18, 2010 at 7:16 PM, Peter Kasting <pkast...@google.com> wrote:
> On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke <dpra...@chromium.org> wrote:
>>
>> 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'd pretty strongly like to not specify steps like these. They duplicate
> code we already have for interpreting user input, except with less fidelity.
> We have quite sophisticated heuristics for how to figure out the correct
> scheme, parse drive letters, UNC paths, etc. We don't need to write another
> set.
> I also don't really care about trying to fix up "www.google.com"; if it
> falls out of the existing code, fine, but I wouldn't bother spending time on
> it. I'm definitely opposed to doing anything like "try DNS resolution on X
> and fall back to Y" since it makes the results unpredictable based on your
> network. What if the user specifies a filename that's also an intranet
> host? What if the user says "www.google.com" but the network is currently
> down -- does the browser show a "couldn't open local file www.google.com"
> error? etc.
> It's enough to simply say "run the input through fixup, supplying the CWD as
> the relative file path base". We have code that can basically take it from
> there.
This sounds fine, although I'd be curious to see where the logic in
fixup differs from the above. I certainly agree that we don't want an
additional code path.
I would perhaps amend "resolve to a valid hostname" to "looks like a
hostname", although I don't know what heuristics we use for that (if
any other than passing it to name resolution).
> PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
