In a bunch of cases, this actually ends up simplifying the code as
to_number will handle something such as:
```
Optional<I> opt;
if constexpr (IsSigned<I>)
opt = view.to_int<I>();
else
opt = view.to_uint<I>();
```
For us.
The main goal here however is to have a single generic number conversion
API between all of the String classes.
This adds a simple and incomplete implementation for extracting some
specific CORS headers that are used by fetch. This unifies the existing
ad-hoc parsing that already existed for Access-Control-Allow-Headers
and Access-Control-Allow-Methods, as well as adding
Access-control-Expose-Headers.
This adds the headers named in Access-Control-Expose-Headers to the
response's CORS-exposed header-name list which allows those headers to
be accessed from JS.
We can't keep a span (ReadonlyBytes) to a move()'d ByteBuffer
in the header_names_seen HashTable - copy the original name span instead
which works the same thanks to CaseInsensitiveBytesTraits.
This would sporadically fail the contains() check due to garbage data,
later leading to a VERIFY() crash in the OrderedHashTable append loop.
Previously, parsing failures and the header not existing made
extract_header_list_values return an empty Optional, making it
impossible to differentiate between the two.
Required for implementing CORS-preflight, where parsing failures for
the headers makes it fail, but not having them doesn't make it fail in
all cases.
Having an alias function that only wraps another one is silly, and
keeping the more obvious name should flush out more uses of deprecated
strings.
No behavior change.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
The header-specific ABNF rules are completely ignored for now, but we
can at least extract a single header value, which at least works for
simple cases like `Location`-based redirects.
This is the way.
On a more serious note, there's no reason to keep adding ref-counted
classes to LibWeb now that the majority of classes is GC'd - it only
adds the risk of discovering some cycle down the line, and forces us to
use handles as we can't visit().
This allows us to use this:
```cpp
auto header = TRY_OR_RETURN_OOM(realm,
Infrastructure::Header::from_string_pair(name, value));
```
Instead of the somewhat unwieldly:
```cpp
auto header = Infrastructure::Header {
.name = TRY_OR_RETURN_OOM(realm, ByteBuffer::copy(name.bytes())),
.value = TRY_OR_RETURN_OOM(realm, ByteBuffer::copy(value.bytes())),
};
```
In particular, StringView::contains(char) is often used with a u32
code point. When this is done, the compiler will for some reason allow
data corruption to occur silently.
In fact, this is one of two reasons for the following OSS Fuzz issue:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49184
This is probably a very old bug.
In the particular case of URLParser, AK::is_url_code_point got confused:
return /* ... */ || "!$&'()*+,-./:;=?@_~"sv.contains(code_point);
If code_point is a large code point that happens to have the correct
lower bytes, AK::is_url_code_point is then convinced that the given
code point is okay, even if it is actually problematic.
This commit fixes *only* the silent data corruption due to the erroneous
conversion, and does not fully resolve OSS-Fuzz#49184.
Turns out HashTable::contains() doesn't solely use hash() for equality
checks, so the lack of a proper equals() implementation broke the check
in convert_header_names_to_a_sorted_lowercase_set() and caused duplicate
entries in header_names_set.
The Fetch spec unfortunately will cause a name clash between the Request
concept and the Request JS object - both cannot live in the Web::Fetch
namespace, and WrapperGenerator generally assumes `Web::<Name>` for
things living in the `<Name>/` subdirectory, so let's instead move infra
code into its own namespace - it already sits in a (sub-)subdirectory
anyway.
