QUrl in KDE 4
Andreas Aardal Hanssen
ahanssen at trolltech.com
Mon May 23 10:31:01 BST 2005
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"
> 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
Andreas Aardal Hanssen - andreas . hanssen @ trolltech.com
Trolltech AS - Waldemar Thranes gt. 98, NO-0175 Oslo, Norway
More information about the kde-core-devel