On Wednesday 17 August 2011 14:26:21 Thiago Macieira wrote:
> The main problem is: what does the following return?
> QUrl("/foo").scheme()
>
> If it's "file"
Yes, in KUrl this returns "file".
> , the following code will not work as expected:
> QUrl base("http://example.com/bar/";);
> QUrl relative("/foo");
> return base.resolved(relative);
The question is, why use QUrl for "relative".
KUrl(KUrl, QString) uses a QString for the possibly-relative url, which fixes
this problem.
> If the QUrl construct can take a URL or a path, then we need a static
> function that can take *only* a URL and never a path.
More precisely, if the QUrl constructor can take absolute URLs, relative URLs,
and paths, then it becomes ambiguous indeed. This still leaves two solutions:
* absolute or relative URLs (like in Qt4), or
* absolute URls or paths (like KUrl)
> And we need to change
> WebKit and other code that deals with URLs exclusively to use that.
Well, if the constructor doesn't take paths, and if we port from KUrl to
direct use of QUrl, then we need to change a lot of code in KDE...
In KDE3 we used to have KUrl::fromPathOrUrl(), and every single developer
would get this wrong somewhere and forget to call it, so we had "rare"
escaping bugs (bugs that only show up with local files containing a '#' in
their name) everywhere.
Local files are much more common in code than relative URLs, which is why I'm
suggesting that the constructor should allow for local paths, even if it makes
things a little bit different for relative urls.
> QUrl("/tmp/Mambo #5.mp3")
>
> Is that:
> path() = "/tmp/Mambo ", fragment() = "5.mp3"
> or path() = "/tmp/Mambo #5.mp3"
Obviously the latter, since it starts with a '/', so it's not an absolute URL.
> > And it should accept both encoded and non-encoded urls (see
> > KUrl::_setEncodedUrl and related tests).
>
> No can do. There will be no such thing as fully-decoded (unencoded) URLs
> anymore. They will be simply forbidden. That's exactly the case of the
> example above: the '#' above is a decoded %23 or is it the delimiter?
>
> Because of that ambiguity, the only way to resolve this problem is to use
> encoded URLs. But the code should accept unencoded characters that aren't
> otherwise special, like the space above.
Well, yes, obviously '#' is ambiguous. But most other chars aren't. So I
agree, as long as the tolerant mode is really tolerant. Example from Qt4:
QUrl dxOffEagle3;
dxOffEagle3.setEncodedUrl( "http://something/newpage.html?[{\"foo: bar\"}]",
QUrl::TolerantMode);
(was fixed for Qt-4.5 if my notes are correct)
> The tolerant mode can only help the bad encodings of %. I've had some ideas
> for how to improve the algorithm, especially being self consistent:
>
> "75% to 95%3f.pdf"
> becomes:
> "75%25 to 95%253f.pdf"
> that is: one bad % means all % are bad, even if they are followed by two
> hexadecimal characters.
Makes sense.
--
David Faure, [email protected], http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
