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

List:       kde-devel
Subject:    Re: KURL bugs
From:       Waldo Bastian <bastian () ens ! ascom ! ch>
Date:       1999-06-17 8:59:42
[Download RAW message or body]

Stephan Kulow wrote:
> > According to the specification,
> >
> > "   ...
> >     A file URL takes the form: file://<host>/<path>
> >     ...
> >
> >     As a special case, <host> can be the string "localhost" or the
> > empty string; this is interpreted as `the machine from which the URL
> > is being interpreted'...".
> >
> > 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 :)

Strictly speaking it doesn't. But having "file:///home/bastian" or 
"file://localhost/home/bastian" instead of a simple "file:/home/bastian"
looks way too messy to me.

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

There is a seperate RFC (rfc2396) covering relative URLs as well. It doesn't 
seem  this has been taking into account while (re)writing KURL. Prepending
the directory name to not-fully qualified URLs makes sense in this respect
though.

> > 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:
> >
> > 1.    file://machinename/sharename/foldername/.../filename
> >
> > In Windows browsers, it is legal to use UNC names with either backward
> > or forward slashes. That is, the following URLs are perfectly legal:
> >
> > 2.    file://localhost/\\machinename\sharename\foldername\filename
> >
> > 3.    file://localhost///machinename/sharename/foldername/filename
> >
> > 4.    file://///machinename/sharename/foldername/filename
> >
> > 5.    file:///\\machinename\sharename\foldername\filename
> >
> > Unfortunately, none of those forms is parsed correctly by the KURL
> > class:
> >
> > For forms #1, #3 and #4 KURL returns path to be
> > "/machinename/sharename/foldername/filename" which is wrong because it
> > fails to notice one leading forward slash which makes all the
> > difference.

This is a bug and should be corrected. I guess the "cleanpath()" function
is partrly responsible for this.

> > For form #2 KURL returns path to be
> > "/\\machinename\sharename\foldername\filename" which is wrong because
> > of the leading forward slash.
> 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 leading slash does indeed belong there.

> > For form #5  KURL incorrectly thinks that
> > '\\machinename\sharename\foldername\filename' is the host name and the
> > path is '/'.

This is a bug.

> > The following forms are not standard but are commonly used in Windows:
> >
> > 5. file://\\machinename\sharename\foldername\filename

The UNC will probably end up in the hostname.

> > 6. file:////machinename/sharename/foldername/filename

This one will probably throw out a '/' to much. Can be fixed.

> > These forms are not correctly parsed by KURL as well.


Thank you for your bug-reports, we will add them to KURL's regression
tests.

Cheers,
Waldo
-- 
KDE, A New Millenium, A New Desktop                      http://www.kde.org

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