[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KURL bugs
From:       Alex Zepeda <garbanzo () hooked ! net>
Date:       1999-06-17 8:49:50
[Download RAW message or body]

On Thu, 17 Jun 1999, Stephan Kulow wrote:

> > In general, URLs are widely across all the modern platforms by various
> > applications and have well documented structure (RFC 1738).

Really, I read the successor to RFC 1738, and IMO it's not all that clear
on any number of things (#2396).

> > Problem description:
> > 
> > Unfortunately, some URLs obtained through KURL class do not conform to
> > the RFC 1738. This happens in the case of the file URL scheme.

Most of them *do* conform, but some of them don't.

> > In KDE, file URLs are formed without two forward slashes following
> > "file:".
> > That is, a local file named "/mnt" will be represented as "file:/mnt"
> > in KDE as opposed to a correct "file:////mnt" or
> > "file://localhost//mnt".
>
> Well, I don't have the RFC handy, but I'm sure it allows file:/mnt too
> as I've read it twice :)

Well, Netscape allows file:/mnt, but not file:/.  Also, file://mnt does
not seem to work.  So, I really see no problem with allowing something
that seems much more logical (since you're usually not specifying a
hostname for a local file system.

> > 
> > Another problem with URLs in KDE is that its applications don't assume
> > that the path is fully qualified and will attempt to append the
> > current directory name in front of any name which doesn't start with
> > '/'.
> right. I don't see this as bug.

What? How does a URI/URL pathname not start with a '/'?

> > The failure to comply with the standard in KURL doesn't create a
> > problem when working with local files whose names are beginning with a
> > single forward slash. However, the problem becomes obvious when we try
> > to use KURL when working with UNC names.
> > 
> > UNC names have the form
> > "\\machinename\sharename\foldername\...\filename".
> > 
> > According to RFC 1738, URL for them should have a form:
> > 
> > In Windows browsers, it is legal to use UNC names with either backward
> > or forward slashes. That is, the following URLs are perfectly legal:
> > 
> > Unfortunately, none of those forms is parsed correctly by the KURL
> > class:
>
> Well, backslash is an legal name pattern, so filenames having them in it
> are very legal. I don't see how we can differ between filename with
> back-slashes and UNC names
> > 
> > The following forms are not standard but are commonly used in Windows:

This is not Windows.  Repeat ten times.

I'm not quite sure how to state this, but:

* What Windows does WRT UNC and "regular" filenames is just annoying as
hell, and really inconsistant.  Sure, it may feel more like windows if
KURL is hacked up to support "true" UNC paths, but this just perpetuates
another level of needless confusion on the user.

* Since there appears to be special handling for any URI with the file
protocol, and since UNC paths won't often be local files (if at all), it
would be best (IMO) to either use //host/path and use the protocol "unc"
or "smb".

- alex

I thought felt your touch
In my car, on my clutch
But I guess it's just someone who felt a lot like I remember you.
  - Translator

[prev in list] [next in list] [prev in thread] [next in thread]