[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: KURL bugs
From: Stephan Kulow <coolo () itm ! mu-luebeck ! de>
Date: 1999-06-17 8:24:21
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic