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

List:       kde-bugs-dist
Subject:    Bug#43800: filenames with ":" are used as io-slave description
From:       "Dawit A." <adawit () kde ! org>
Date:       2002-06-12 5:11:18
[Download RAW message or body]

On Wednesday 12 June 2002 00:10, Dawit A. wrote:
> On Tuesday 11 June 2002 06:59, Stephan Kulow wrote:
> > On Tuesday 11 June 2002 12:06, gerd.mayer@neuro.informatik.uni-ulm.de 
wrote:
> > > Package: konqueror
> > > Version: 4.0 (using KDE 3.0.1 )
> > > Severity: normal
> > > Installed from:    compiled sources
> > > Compiler:          gcc version 2.95.3 20010315 (SuSE)
> > > OS:                Linux (i686) release 2.4.18
> > > OS/Compiler notes:
> > >
> > > at least while browsing local webpages, i discoverd, that an hyper-ref
> > > with an filename, that contains ":" like the one in the following
> > > example
> > >
> > > <a href="Kraetzschmar+Enderle:02:RAS_bib.html"> BibTeX-Entry </a>
> > >
> > > leads to the result, that klauncher think, the first part is an
> > > io-slave. this leads to the following error:
> > >
> > > An error occured while loading kraetzschmar+enderle:02:RAS_bib.html:
> > >
> > > Could not start process Unable to create io-slave:
> > > klauncher said: Unknown protocol 'kraetzschmar+enderle'.
> >
> > Because : has a defined meaning in URLs. If you can find a RFC where it
> > says that HTML hrefs can contain :s unencoded, then fine, til then I tell
> > you that you have to write the : as %2e
>
> That is not true.  See RFC 2396 section 3.3.  The ":" just like the "+"
> character in the above example is allowed within the path component of
> a URL.  The problem here is that KURL escape encodes/decodes URLs as a
> whole instead of on a component by component basis, i.e. path, query,
> fragment etc. RFC 2396 clearly states that characters allowed in one
> component are not necessarily allowed in another and there are characters
> that are deemed completely unsafe in all components unless they are escape
> encoded, for example spaces.
>
> Regards,
> Dawit A.

Although what I said is valid in general, my argument in this instance is 
wrong and Stephan's explanation is correct. The order in which URL's are 
resolved within HREF element dectates how the given URL is interpreted.  In 
this case the URL is seen as a valid opaque URL, same thing as say 
mailto:foo@bar.com, and hence khtml attempts to find a handler io-slave for a 
"kraetzschmar+enderle" protocol instead of treating the whole thing as a 
relative URL, i.e. just a filename ; so please ignore what I said above since 
it is only valid for general cases and fully qualified URLs, for example:

http://www.kde.org/somefile:20:pages.html (bogus example) or if you take the 
above URL in the HREF and replace the filename part of the Base URL for the 
document this link appeared in, everything should work correctly...

Regards,
Dawit A.

(Complete bug history is available at http://bugs.kde.org/db/43/43800.html)
[prev in list] [next in list] [prev in thread] [next in thread]