The QNetworkReply::NetworkError enum mixes all kinds of errors into one
enum, HTTP errors, network errors, proxy errors, etc.
Instead of caring about it, we now say that HTTP requests were
successful if their response has any HTTP status code attached.
This allows LibWeb to display error pages when using Qt networking.
The slowdown is sometimes 5x, possibly more.
This is trivially confirmed by adding a large JS file to a page and
comparing the load time with a simple wget.
Qt can wrap any number of cookies into a single Set-Cookie header in the
network responses it gives us. We now use the QNetworkReply::header()
API to get a "cooked" list of the cookies, and then rewrap them in a
format suitable for LibWeb.
Sites that send multiple Set-Cookie headers in one response now work
a lot better. :^)
- Silences the -Wuser-defined-literals warning which is triggered by our
use of the `sv` suffix for StringView
- Removes an unused captured `this` pointer [-Wunused-lambda-capture]
- Changes a JSONArray.h include to JSONObject.h to get the definition
for `JSONValue::serialize`. This is needed because template functions
are not exported for dylibs on macOS. This is a hack; the JSON headers
should be refactored so that each one includes the definition of
the template functions it sees. -- Maybe we should build with
-fvisibility-inlines-hidden on Linux to catch issues like this?
Until we can get our own RequestServer infrastructure up and running,
running the TLS and HTTP code in-process was causing lots of crashes
due to unexpected reentrancy via nested event loops.
This patch adds a simple backend for HTTP and HTTPS requests that simply
funnels them through QNetworkAccessManager.
