On Thursday, 18 de August de 2011 14:43:51 David Faure wrote:
> 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.
Because it's a relative URL. Think of the following example:
QUrl relative("/cgi-bin/postdata.cgi?foo=bar#anchor");
Sure, a QString can be parsed at the time of making the relative data, but it
is a URL. It is valid to have scheme-less, relative URLs.
So even if we add the overload, there's no reason not to have a QUrl one and
you still need to construct a QUrl that is relative.
> > 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...
Or you can use a convenience wrapper called KUrl until such porting is done.
Whereas changing QUrl behaviour introduces subtle bugs.
> 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.
Maybe we should remove the constructor altogether then?
> 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.
It is a valid, absolute URL with an empty scheme and empty authority. So you
cannot exclude it.
The case of having to parse it is very common: the string comes from a webpage
or script and the web engine code needs to decide whether it is cross-domain
scripting or not. So it needs to treat the string as a URL.
If that string is "/foo", it is clearly meant as relative to the current
webpage. If we interpret that as "file:/foo", then the code might conclude it
is a cross-domain scripting.
In any case, it doesn't solve the problem of a string that does not start with
a slash: in that case, is it "file" or not?
Also note that another source of mistakes has been fixed in Qt 4.8: if the
scheme is empty, then toLocalFile() returns empty too. So if you write the
mistaken code:
QUrl url(string);
QFile f(url.toLocalFile());
the file will fail to open. If you write the less mistaken but still mistaken:
QUrl url(string);
QFile f(url.path());
then the behaviour is consistent. And in any case, neither solution solves the
problem I saw today on IRC:
QUrl url("file:///" + string);
> > > And it should accept both encoded and non-encoded urls (see
> > > KUrl::_setEncodedUrl and related tests).
> >
> 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)
I don't get what this example is trying to show. The URL is not ambiguous.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
