I was trying to port openttd which I ultimately gave up on because
too much of the C++ standard library's functionality is missing at this
point. The libicu library was a dependency for that.
In its current state the libicu port is not thread-safe because of
missing functionality in the C++ standard library (mainly std::mutex,
std::condition_variable, etc.).
This is useful for ports which depend on running tools on the host system.
In this case we can build the port twice - once for the host and once for
the target system.
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.
Since our tests usually take at least 10 minutes theres no point in
checking every 10 seconds, and github was starting to complain about
the very high API usage.
I'd rather use libtool to build the library but that would
require more extensive changes to the configure script
and maybe even libtool itself. So instead I just build
it manually.
Reading from the mapping doesn't work when the text segment has a non-zero
offset because in that case the first mapped page doesn't contain the ELF
header.
Otherwise these will get their name/default message from the Error
prototype, and as a result would always just say "Error" in error
messages, not the specific type.
Something I missed in da177c6, now with tests. :^)
It looks like some particularly long builds (After a toolchain cache
reset and on a slow worker) can take much longer than the current set
timeout of 20 minutes.
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".
