Leading and double dots are bad, but trailing dots are fine. The ASCII
part of a hostname is supposed to be LDH (letters, digits, hyphen) only,
but we accept '_' (underscore) as an exception too.
Change-Id: I79957ddec4da78a0e2357fe50c8687db03e1c99e
Reviewed-by: David Faure (KDE) <faure@kde.org>
qt_nameprep is tested by tst_qurlinternal. We just need to be sure that
QUrl handles them correctly.
Change-Id: Ic563004870d2cf2fa7a31ce49fff7280d5ffb5f3
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Most notably, .com and .net now may contain non-ASCII characters.
list has been generated from
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
Change-Id: Idc3191dc782bc4173ccb19b4bc81f4f061ca7999
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The table is there to know which domains are allowed to set cookies
and which are not. There are more than 2000 new entries since the
list has last been generated.
The split to 64K chunks was made because this is the hard limit for
strings in Visual Studio.
Change-Id: I511aec062af673555e9a69442c055f75bdcd1606
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These tests were added to Qt 4 on commit
a17fc85b51a6bdcfa33dcff183d2b7efd667fb92
Task-number: QTBUG-28985
Change-Id: I3cf595384f14272197dcfb85943213c8f8ddeba0
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This is a very common thing to do, e.g. in order to send urls via DBus.
Change-Id: I277902460ee1ad6780446e862e86b3c2eb8c5315
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QUrl::fromUserInput("http://") was invalid, which doesn't make sense
since QUrl("http://") is valid. Same for "smb:" which is actually
even more a valid URL from a user's point of view.
Change-Id: I371ac393d61b49499edf5adbbc2a90b426fe9e5d
Reviewed-by: Marco Martin <mart@kde.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These cases weren't handled before.
The validateComponent function is copied from QUrlPrivate::parse, with
the added modification that it now needs to check the gen-delims for
the userinfo.
Change-Id: I055167b977199fa86b56a3a7259a7445585129c6
Reviewed-by: David Faure (KDE) <faure@kde.org>
... with respect to empty and null strings.
Change-Id: Ic107d5bcc8b659497a567b75a7244caceba5a715
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Keep the original QString that triggered the parsing error, instead of
just one QChar. This provides more powerful error messages, like:
Invalid IPv6 address; source was "http://[:::]"; scheme = "http", host = ""
(QUrl cannot keep invalid hostnames)
Invalid port or port number out of range; source was "http://example.com:abc"; scheme = "http", host = "example.com"
(QUrl cannot keep a non-numeric port number)
Invalid path (character '%' not permitted); source was "foo:/path%?"; scheme = "foo", path = "/path%25%1F"
(the tolerant parser runs first, so the faulty component is fixed)
This stores the error state in a special structure which is not
allocated under normal conditions, keeping the memory consumption
down. On 32-bit systems, QUrlPrivate does not increase in size; on
64-bit systems, it grows by 8 bytes.
Change-Id: I93d798d43401dfeb9fca7b6eed7ea758da10136b
Reviewed-by: David Faure <faure@kde.org>
Make both invalid hostname messages start with "Invalid hostname". And
split the empty port error from the invalid port one.
Change-Id: I870d1ed6fb07ec494f553871a37ed167141ffc06
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
That's what we have QUrl::errorString() for. This will become evident
especially now that QUrl::toString() / toEncoded() return empty if
there are errors.
Change-Id: I64a84e9c6ee57c0fc38cc0c58f5286ddc1248d1f
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Reviewed-by: David Faure <faure@kde.org>
These two errors can only happen if one calls setPath() explicitly. They
cannot happen for parsed URLs, which is why they are only caught with
isValid(). It's not possible to set the error condition in setPath()
either because they depend on the presence / absence of the authority
and scheme.
Also update all the unit tests that set a path not starting with a slash
and were just "freeloaders" on the previous behaviour.
Change-Id: Ice58cd4589a850452d7573a5b19667bbab2fb43e
Reviewed-by: David Faure <faure@kde.org>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
This detected the same missing detach()s in QUrl::resolve.
Everything else works, no need for a mutex in Qt5's QUrl.
Change-Id: I0da51b7b0c6b810d314a26d4b638383cd17de12b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The asymmetry is intentional: the getters can use toLatin1() because the
called functions, with a QUrl::FullyEncoded parameter, return ASCII
only. This gives a small performance improvement over the need to run
the UTF-8 encoder.
However, the data passed to setters could contain non-ASCII binary data,
in addition to the percent-encoded data. We can't use fromUtf8 because
it's binary and we can't use toPercentEncoded because it already encoded.
Change-Id: I5ecdb49be5af51ac86fd9764eb3a6aa96385f512
Reviewed-by: David Faure <faure@kde.org>
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.
Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Ensure that the parsing mode is cascaded down from setAuthority and
setUrl so that the hostname parsing does not attempt to decode
percent-encoded hostnames when it shouldn't.
Take the opportunity to also remove the "Boolean Trap" from
QUrlPrivate::setHost.
Change-Id: Ia64754c4a4900182700b7af1382aea8410abc7e9
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The URI RFC defines schemes as containing only a very restricted set
of characters, none of which require encoding, so don't even
try. Testing this behaviour in some web browsers indicate that they do
not accept percent-encoded schemes either.
Change-Id: I692dd20e1aac7e8a1bcb276cb5113b5802393d38
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
If the password is empty (but present), the userinfo component of the
URL should end in a colon (":"). QUrl already supported that and it
was tested (case "password-empty").
If the username is *also* empty but present, the userinfo component is
just the colon (":"). Fix support for that case by checking if we
stored the presence flag instead of checking the size of the
component.
Change-Id: Ie224493a997dbf76b2e44dd6d55fd9674ac83c1c
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
QString::fromUtf8, without an explicit size, (currently) defaults to
stopping at the first NUL. That means we need to pass an explicit
size.
Also take the opportunity to test that QUrl::toPercentEncoding also
works with the same data.
Change-Id: I79362d67afda624b01ca07b0315b611c4aa3fdda
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: David Faure <faure@kde.org>
When given an invalid url, the output shouldn't be a valid url.
KDE's kurltest detected this regression compared to Qt4, where
all invalid urls were empty in toString() -- but we don't want that,
to give as much feedback as possible to the user.
Change-Id: Ie53e6e1c0a1d4bb9e12b820220dfb7e2f7753959
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows the QUrl component getters to return fully decoded data,
like they did in Qt 4. This is necessary for some use-cases where the
component like the user name, password or path are used outside the
context of a URL. In those contexts, the percent-encoded data makes no
sense, and the loss of data of what could be represented in a URL is
acceptable.
Also take the opportunity to expand the documentation of those getter
methods, explaining what the options argument does.
Discussed-on: http://lists.qt-project.org/pipermail/development/2012-May/003811.html
Change-Id: I89f743cde78c02f169c88314bff0768714341419
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This allows one to instruct QUrl to ignore the percent-encodings and
interpret the data exactly as provided. This is useful in certain
use-cases where the data comes from a non-URL context.
The strict-mode checking of the components is not implemented
yet. Currently, the behaviour is equal to that of TolerantMode.
Discussed-on: http://lists.qt-project.org/pipermail/development/2012-May/003811.html
Change-Id: Ia5abe045a8ce7f9b50cbce3b5a7e3735e068d03a
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Since we're about to introduce QUrl::FullyDecoded, this
QUrl::MostDecoded value would be confusing. Replace its uses with what
was intended at the point in question.
Change-Id: Iefd87bc33d37bace507c5cb0f206fa902e08e2df
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
QUrl::fromLocalFile("/foo") doesn't set Host, but QUrl("file:///foo")
does (to remember that it saw a Host section, even if empty, which is
useful for urls like "remote://"). So ignore the Host flag in operator==.
Change-Id: I4322b4a75420c4e42766c0d65c1b121f28028a76
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fix operator== and operator< so that a URL with an empty fragment
or query, is not treated as equal to a URL without any fragment or query.
This restores the Qt4 behavior on this particular issue.
Change-Id: Ie989f37353fb13c791b1d558d638d2e8a5b5d1b8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Null bytearray means no query, and QString::fromLatin1(QByteArray())
doesn't give a null string, but an empty string.
Same for setEncodedFragment(QByteArray()).
Change-Id: I992e9253e35941d66886456872ea06aa2ae92450
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was crashing because the ':' was found past the end of the
username, causing the recoder to run from position 22 to 11, via the
long way around the memory.
Change-Id: Ic1ae596f34f7db857fb4210294974fb5a6adf691
Reviewed-by: Alexis Menard <alexis.menard@openbossa.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Show that nothing is changed either way, regardless of the encoding
flags used.
Change-Id: I31fba5f87eae777d4b708ab789b32169004bcbcc
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
It should only strip one slash (as the name indicates), and not if the
path is just "/".
Change-Id: I133a81977241de77a49d1d1559143d30e0bd52f8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unlike path(), toLocalFile() isn't reporting a URL component, so it
should decode the percent-encoded characters fully. This extra
decoding pass is meant to catch %00 to %1F, %7F and %25 (the percent
sign itself).
It also catches %80 to %FF, which aren't decoded because they don't
form UTF-8 sequences. That means QUrl::toLocalFile() has undefined
behaviour if the path contained non-UTF8 sequences.
Task-number: QTBUG-25459
Change-Id: Iab5a0ba6afcfc4510e297984f2ffc208cedd752b
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Instead of trying to return whether the URL is relative to something
undefined, let's instead follow what the documentation was saying all
along and what the RFC says about "Relative References".
Change-Id: I32722321a6b36c6e3480669ad769390e4c6f7d1c
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
QUrl::path() already decodes almost everything, but let's pass the
formatting flag to be sure.
Note: decoding of control characters from U+0001 to U+001F is not
implemented. Non-UTF8 sequences are also not representable.
Change-Id: I9a0ae2282ec3d48cc0e70e5b2d3824fb120709ed
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
It's perfectly valid to have a path of /c:/a.txt on Unix, so don't
strip the leading slash unless we're on Windows.
Task-number: QTBUG-20322
Change-Id: I721bd0a65b41048bc735d4eaa0d536174164fe64
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
The new QUrl is able to distinguish a URL component that is empty from
one that is absent. The previous one already had that capability for
the port, fragment and query, and the new one extends that to the username,
password and path. The path did not need this handling because its
delimiter from the authority it part of the path.
For example, a URL with no username is one where it's set to QString()
(null). A URL like "http://:kde@kde.org" is understood as an
empty-but-present username, for which toString(RemovePassword) will
return "http://@kde.org", keeping the empty-but-present username.
Change-Id: I2d97a7656f3f1099e3cf400b199e68e4c480d924
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Most of the tests were removed while QUrl::toEncoded or fromEncoded
were deprecated in the development process. Since they aren't
deprecated in the end, bring them back.
Change-Id: Ibdb6cd3c4b83869150724a8e327a03a2cd22580d
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
By having the default value equal to zero, we follow the principle of
least surprise. For example, if we had
url.path()
and we refactored to
url.path(QUrl::DecodeSpaces)
Then instead of ensuring spaces are decoded, we make spaces the only
thing encoded (unicode, delimiters and reserved characters are
encoded).
Besides, modifying the default can only be used to encode something
that wasn't encoded previously, so having the enums as Encode makes
more sense.
As a side-effect, toEncoded() does not support any extra encoding
options.
Change-Id: I2624ec446e65c2d979e9ca2f81bd3db22b00bb13
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This allows things like http://example.com/{1234-5678}?id={abcd-ef01}.
But do not allow it in other parts of the URL. I could allow it in the
fragment, but in the username and password it would be too ugly.
In order to do that, make DecodeReserved use two bits and have
PrettyDecoded set only one of them. That way, toString(PrettyDecoded)
can be distinguished from toString(PrettyDecoded | DecodeReserved),
just as path(PrettyDecoded) can be distinguished from
path(PrettyDecoded & ~DecodeDelimiters).
Also, take the opportunity to avoid decoding the reserved characters
in the query. Keep them encoded as they should be.
Change-Id: I1604a0c8015c6b03dc2fbf49ea9d1dbed96fc186
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
DecodeReserved applies to all characters between 0x21 and 0x7E that
aren't unreserved, a delimiter, or the percent sign itself.
Change-Id: Ie64bddb6b814dfa3bb8380e3aa24de1bb3645a65
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
There's little value in having the DecodeUnambiguousDelimiters option
since neither QUrl nor QUrlQuery can return values that are ambiguous
in that particular context, ever.
This option could be used to encode a character if, when placed
in a URL, it would need to be encoded. Such cases are hash (#) or
question marks (?) in the path component, or slashes (/) and at signs
(@) in the userinfo.
However, we don't need two enums for that, since there are no
other characters that can appear in either form. Still, leave two bits
for this enum. In the future, if we want to split the gen-delims from
the sub-delims, we are able to.
Change-Id: If5416b524680eb67dd4abbe7d072ca0ef7218506
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This tests how QUrl encodes and decodes certain characters and leaves
some other ones alone. It also tests that the output of toString() (in
whichever encoding was being tested) is also parsed again to be
exactly the same as the previously decoded form.
Change-Id: Ie358d001f8b903409db61db48bde1ea679241a60
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
