On Thursday 18 August 2011 17:45:41 Thiago Macieira wrote:
> 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.
Some of the QUrl API doesn't make sense for relative urls though (scheme(),
host(), etc. are empty), and you can't pass such a URL to networking code
(e.g. QNetworkAccessManager), so it's not really usable as is.
But OK, it looks like I won't change your mind about this, so let's assume
relative QUrls for the rest of the discussion...
> > 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?
Yes, that would actually be the safest way.
Depending on the use case, there are so many ways to construct a QUrl from a
QString:
- local path
- complete url
- relative url
- user input which could be a local path or a complete url
A single constructor can't know which one is meant, and we can't honestly say
which one is the most common case, (and risk breaking the other cases because
people will just use the constructor which will do the wrong thing).
Therefore the best solution would be 4 static methods.
Or a constructor with a mandatory flag argument.
> > > 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.
Sounds like an RFC point of view. For any practical purposes, a URL without a
scheme is not absolute - you don't know how to get that data.
> 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.
Isn't the solution to resolve the URL first, and then compare it with the
current domain?
> 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?
No.
> > > > 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.
That's what I was saying: as long as the tolerant parser is really tolerant
with things that are NOT ambiguous (even if they are not encoded enough to be
RFC-compliant), I agree with not having a distinction between encoded and non-
encoded urls in the API.
--
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
