Function-local `static constexpr` variables can be `constexpr`. This
can reduce memory consumption, binary size, and offer additional
compiler optimizations.
This removes StringView::find_first_of(char) and find_last_of(char) and
replaces all its usages with find and find_last respectively. This is
because those two methods are functionally equivalent.
find_{first,last}_of should only be used if searching for multiple
different characters, which is never the case with the char argument.
This also adds the [[nodiscard]] to the remaining find_{first,last}_of
methods.
Problem:
- `static` variables consume memory and sometimes are less
optimizable.
- `static const` variables can be `constexpr`, usually.
- `static` function-local variables require an initialization check
every time the function is run.
Solution:
- If a global `static` variable is only used in a single function then
move it into the function and make it non-`static` and `constexpr`.
- Make all global `static` variables `constexpr` instead of `const`.
- Change function-local `static const[expr]` variables to be just
`constexpr`.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
To protect the main Browser process against nefarious cookies, parse the
cookies out-of-process and then send the parsed result over IPC to the
main process. This way, if the cookie parser blows up, only that tab
will be affected.
To implement the HttpOnly attribute, the CookieJar needs to know where a
request originated from. Namely, it needs to distinguish between HTTP /
non-HTTP (i.e. JavaScript) requests. When the HttpOnly attribute is set,
requests from JavaScript are to be blocked.
This moves the cookie parsing steps out of CookieJar into their own file
inside LibWeb. It makes sense for the cookie structures to be in LibWeb
for a couple reasons:
1. There are some steps in the spec that will need to partially happen
from LibWeb, such as the HttpOnly attribute.
2. Parsing the cookie string will be safer if it happens in the OOP tab
rather than the main Browser process. Then if the parser blows up due
to a malformed cookie, only that tab will be affected.
3. Cookies in general are a Web concept not specific to a browser.
The spec doesn't have any exact steps here, it just notes:
The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store.
Here, we implement "at any time" as "when a cookie is retrieved or
stored".
https://tools.ietf.org/html/rfc6265#section-5.3
This includes a bit of an update to how cookies are first parsed. The
storage spec requires some extra information from the parsing steps than
just the actual values that were parsed. For example, it needs to know
whether Max-Age or Expires (or both) were specified to give precedence
to Max-Age. To accommodate this, the parser now uses an intermediate
struct for storing this information. The final Cookie struct is not
created until the storage steps.
The storage itself is also updated to be keyed by a combo of the cookie
name, domain, and path.
Retrieving cookies was updated to use the spec's domain-matching
algorithm, but otherwise is not written to the spec yet. This also does
not handle evicting expired cookies yet.
Setting the year to NumericLimits<unsigned>::max() resulted in the
following datetime: -2-12-31 00:00:00.
Instead, set the latest datetime to the last second of the year 9999.
Note: the default expiry time should be the "the latest representable
date". However, DateTime::from_timestamp(NumericLimits<time_t>::max())
isn't feasible due to the for-loops in LibC's time_to_tm. So instead,
this just sets the date to the maxium year.
This adds storage for cookies that maye be set via 'document.cookie' in
JavaScript or the Set-Cookie HTTP header. For now, it parses only the
name-value pair from a set-cookie line, but does not parse optional
attributes.
Currently, storage is ephemeral and only survives for the lifetime of
the Browser instance.
