PATCH: KURL

[Dawit A.]

On Tuesday 11 February 2003 12:36, David Faure wrote:
> > Currently KURL does not correctly deal with opaque (non-heirarchical)
> > urls. An example of such url is "mailto:". Currently all opaque urls are
> > treated just like absoulte path based hierarchical urls, i.e. like the
> > "file:" protocol/scheme.  This however is completely wrong according to
> > the specifications in RFC 2396. The characters allowed in opaque urls is
> > different from what is allowed in paths.
>
> So it's only the parser part that should be fixed, no?

No, not only the parser, but also the copy ctors and ::url() function to make 
sure m_bIsOpaque is updated or used appropriately.  Other than that though 
yes this should only affect the parser.

> I don't see why fixing the parser also means changing the public behaviour
> of KURL.

I already came to this conclusion, but for a different reason.  My patch 
actually broke ::url() pretty bad for opaque URLs since anything that has 
host will automatically have // attached and also since I made path() return 
the same thing as host() for opaque urls, the non-protocol part got 
duplicated!  So I've reverted this back to previous behavior with minor 
modification to account for opaque urls.

> You say it's better, but I don't see why host() is better than path()
> in mailto:foo. It's really a matter of definition, and KURL defined that
> one calls path to get 'foo'. It works, I see no reason for changing it.

Right. And I've reverted this back albeit for a slightly different reasons I 
outlined above. However, while working on this issue I have come upon a 
larger problem that has been outstanding for a while. This is the problem 
with how we encode the different parts (components) of a url.  But that can 
wait for another patch.

> > BTW, this fix passes all the tests in kurltest, except the two local url
> > once that have been marked "Broken stuff". A patch to comment those out
> > is attached as well.
>
> Those are tests for broken urls, but the tests actually passed, so it is a
> regression if such urls are not handled the same anymore.....

Ehh... I take an issue with this.  If something behaved incorrectly and 
returned one set of results and when it gets fixed it returns another, should 
that be considered a regression ?? Even if it is, is it acceptable to support 
wrong behavior in the name of previous compatibility ?

I see no valid reason why KURL returns "a" as the path when the url specified 
is "file:a"!  This is not only inappropriate, but completely wrong. The 
reason we had filters in the first place is to fix such typos or add 
workarounds if necessary and leave KURL unencumbered.

Regards,
Dawit A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kurl3.diff
Type: text/x-diff
Size: 6076 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030212/5b29636b/attachment.diff>