QUrl in KDE 4

[Andreas Aardal Hanssen]

On Friday 20 May 2005 13:22, Thiago Macieira wrote:
> >> QUrl follows the URI specification in this respect. QUrl does the
> >> right thing in rejecting it. If KUrl accepted this stuff, then that's
> >> really bad.
> >I don't understand this point. What is the problem here? From what I
> > remember, the only thing that the URI specification says is that
> > everything is allowed behind the <protocol>: - unless protocol is among
> > <pretty small list>
> The problem is that KURL in the KDE 3.2 developing days started using IDNA
> and the "hostname"
> 	|file|Ugly_looking[file]name|343928602|00000000000000000000000000000000|
> was being passed to the IDNA functions. Since it is not a hostname, this
> generated many different errors, the foremost being the enforcement of
> the 64-character limit per label. What's more, it lowercases the name,
> since hostnames are case insensitive. And it violates the STD3 rules for
> ASCII-only hostnames. ([, ], | aren't allowed)
> The culprit here is the // just behind ed2k:. If it weren't there, this
> mess would never have happened. Or if the eDonkey 2000 authors used a
> sane URL in the first place.

Hi, everyone. I'll try to answer all questions at once here.

The RFC we are referring to is RFC 3986. QUrl implements this standard, and 
hence, it is a complete URI implementation.

Section 1.1.3 talks about the difference between a URI, a URL and a URN. The 
name and API are designed after the URL; a subset including the network 
location of the resources. But QUrl does it all.

The spec does not describe a generic URI as /^scheme:(.*)$/. KUrl may have
used a simple string split, search for the next '/' if not then and +2 / 5 ;-)
but QUrl doesn't. So I'm really sad, but if there is software out that that 
uses strings that look like URIs but are not, then QUrl can not be used to 
parse it.

Andreas

-- 
Andreas Aardal Hanssen - andreas . hanssen @ trolltech.com
Trolltech AS - Waldemar Thranes gt. 98, NO-0175 Oslo, Norway