Web specs do not return through javascript percent decoded URL path
components - but we were doing this in a number of places due to the
default behaviour of URL::serialize_path.
Since percent encoded URL paths may not contain valid UTF-8 - this was
resulting in us crashing in these places.
For example - on an HTMLAnchorElement when retrieving the pathname for
the URL of:
http://ladybird.org/foo%C2%91%91
To fix this make the URL class only return the percent encoded
serialized path, matching the URL spec. When the decoded path is
required instead explicitly call URL::percent_decode.
This fixes a crash running WPT URL tests for the anchor element on:
https://wpt.live/url/a-element.html
(cherry picked from commit cc557323326ba55514ef2a8a6e0efd7f09330f06;
amended heavily to call `URL::percent_decode()` on all results of
`url.serialize_path()` in the rest of serenity -- except in
LibGemini, where it looked incorrect, and in LibHTTP, where
LadybirdBrowser/ladybird#983 will add it.)
There were some extra steps in there which produced wrong results for
relative file URLs.
Fixes 7 test cases in: https://wpt.live/url/url-constructor.any.html
We also need to adjust the test results in TestURL. The behaviour tested
does not match how URL is specified to work as an absolute relative is
given.
(cherry picked from commit 8723f72f0f2ddabbdd2335afca6124f41ba5f267)
Doing it is not part of the spec. Whenever needed, the spec will
explicitly percent decode the username and password.
This fixes some URL WPT tests.
(cherry picked from commit f511c0b441a591bc85f409242229c7b295e118e4)
We were previously not checking for C0 control, U+0025 (%), or U+007F
DELETE.
This makes another good set of URL tests in WPT pass :^)
(cherry picked from commit fdf4f1e887df18bfb51d2c4d8cc469bc75cc016f)
This fixes an issue where entering EXAMPLE.COM into the URL bar in the
browser would fail to load as expected.
(cherry picked from commit 1a4b042664f8fddbfa70f009c5873b1f8575bf0b)
This is a fetching AO and is only used by LibWeb in the context of fetch
tasks. Move it to LibWeb with other fetch methods.
The main reason for this is that it requires the use of other LibWeb AOs
such as the forgiving Base64 decoder and MIME sniffing. These AOs aren't
available within LibURL.
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
