From kde-devel  Thu Jun 17 08:24:21 1999
From: Stephan Kulow <coolo () itm ! mu-luebeck ! de>
Date: Thu, 17 Jun 1999 08:24:21 +0000
To: kde-devel
Subject: Re: KURL bugs
X-MARC-Message: https://marc.info/?l=kde-devel&m=92960724905564

Ming Poon wrote:
> 
> As promised, here is just a simple but important bug to get fixed so
> that things will work the way they should and will avoid the eventual
> chaos of different apps making different assumptions. How about fixing
> this simple bug? Thanks.
> 
> ----------------------------------------------------------------------
> 
> Background:
> 
> KURL is a KDE core class responsible for handling of URLs. It provides
> certain URL parsing mechanisms as well as static functions for URL
> encoding/decoding.
> 
> In general, URLs are widely across all the modern platforms by various
> applications and have well documented structure (RFC 1738).
> 
> 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.
> 
> 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 :)
> 
> 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.
> 
> 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.
> 
> 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
> 
> For form #5  KURL incorrectly thinks that
> '\\machinename\sharename\foldername\filename' is the host name and the
> path is '/'.
> 
> The following forms are not standard but are commonly used in Windows:
> 
> 5. file://\\machinename\sharename\foldername\filename
> 
> 6. file:////machinename/sharename/foldername/filename
> 
> These forms are not correctly parsed by KURL as well.
> 


Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online