On Wednesday, 17 de August de 2011 11:19:11 David Faure wrote: > On Monday 15 August 2011 15:42:20 Thiago Macieira wrote: > > Hello all > > > > So I've given some thought on QUrl in Qt 5, based on experience with > > > improving it in Qt 4 as well as KUrl. Here's the major guidelines: > Good plans. > > > - the setters will take an extra flag of type QUrl::ParsingMode > > (StrictMode > > > > and TolerantMode). Default should be TolerantMode. > > What about the QUrl(QString) constructor? Can you make it parse in tolerant > mode?
Yes, it should be
explicit QUrl(const QString &encodedUrl, ParsingMode mode =
TolerantMode)
The argument is as I outlined before: percent-encoded Unicode. Not the current
fully-decoded flawed strings.
> Ideally, could it accept both local paths and urls, like KUrl does?
That's what we discussed during the Contributor Summit, but I am now leaning
against it. See https://bugreports.qt.nokia.com/browse/QTBUG-19827 for the
discussion.
The main problem is: what does the following return?
QUrl("/foo").scheme()
If it's empty, then the QUrl is *not* a local file path.
If it's "file", the following code will not work as expected:
QUrl base("http://example.com/bar/";);
QUrl relative("/foo");
return base.resolved(relative);
The above would return "file:/foo", as opposed to the expected
"http://example.com/foo";.
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. And we need to change WebKit and
other code that deals with URLs exclusively to use that.
> This is extremely convenient, compared to having to sprinkle the code with
> fromLocalFile() everywhere, and getting runtime bugs when forgetting to do
> so.
Indeed, but it's also very inconsistent, as the example above showed. Also,
how about?
QUrl("/tmp/Mambo #5.mp3")
Is that:
path() = "/tmp/Mambo ", fragment() = "5.mp3"
or path() = "/tmp/Mambo #5.mp3"
> 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.
> Generally, we have little control over urls from the web, so better have a
> as- tolerant-as-possible constructor. More useful than getting an invalid
> url and having to work around it in a thousand apps.
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.
> > - I'm wondering: should I add a mode that returns the entry
> > non-normalised?
> >
> > i.e., if you write:
> > QUrl("http://localhost/%66%6f%6f";)
> >
> > usually:
> > path() = "/foo"
> >
> > but should we have this?
> >
> > path(Original) = "/%66%6f%6f"
>
> Is this what encodedPath() used to do? I forgot what the usefulness might be
> though, maybe this is for sending to http servers (broken ones, which don't
> consider /foo and /%66%6f%6f as equivalent)?
That's not what it did. The current code splits between unencoded form and
encoded, but none of them keep the original.
This was mostly a thought for dealing with bad URLs. We keep most of the
original and let upper layers deal with brokenness if they have to. And also
because of the + and %2b problem in queries.
> > [...]
>
> OK.
>
> My real feedback will come from kurltest once ported to Q5Url :-)
--
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
