This change causes HTTP status codes to be set on cached HTTP responses.
Otherwise, without this change, no status codes at all are set on cached
HTTP responses — which causes all cached responses to default to being
loaded/served with a 200 status code. And as a result of that, if the
cached response is from a 30x redirect, then without this change, when
that cached 30x response is loaded, we don’t follow the redirect —
because we see a 200 status, rather than the expected/original 30x.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/863
Note that this change also reverts the temporary workaround added in
https://github.com/LadybirdBrowser/ladybird/commit/f735c464d3f
(https://github.com/LadybirdBrowser/ladybird/pull/899).
(cherry picked from commit 23da1752b50568f2c49b1c63c2777ddffddaf6f5)
If a HTTP 401 response we get does not contain a `WWW-Authenticate`
header, we should not trigger the logic to ask the user for credentials
and retry the request.
This part is hinted at in a TODO / 'Needs testing' remark in the spec
but needs to be fleshed out. Raised an upstream issue to do so:
https://github.com/whatwg/fetch/issues/1766
This fixes login forms triggering an infinite fetch loop when providing
incorrect credentials.
Co-Authored-By: Victor Tran <vicr12345@gmail.com>
(cherry picked from commit e7984a77116d47fde150f81f6e18cae6aaa147ad)
This change disables caching for 301, 302, 303, 307, and 308 responses.
This is just for now, ad-hoc — not adhering to any particular spec.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/863
(cherry picked from commit f735c464d3fe02ac43a1fa46c82ae9a3bb5de8b1)
This also changes fetch to use the preferred languages for the
Accept-Language header.
(cherry picked from commit 2ca8fd1832462c05fdec16a1de73494820597140)
This patch adds a simple in-memory HTTP cache to each WebContent
process.
It's currently off by default (turn it on with --enable-http-cache)
since the validation logic is lacking and incomplete.
(cherry picked from commit a3c8e60710451c1325f6718b253e8d1ee2029a30)
This is currently no-op and a FIXME exists to implement the "consume a
preloaded resource" AO.
(cherry picked from commit aee77b975cdd2efddb57a4648c84d4e208cf50c9)
Made easier now that URL percent encode after encoding is also not
throwing any errors. This simplfies a bunch of error handling.
(cherry picked from commit df4739d7ced4159deb2b3e40ba6a1a08b7e7dd5b)
This simplifies a bunch of places which were needing to error check and
convert from a ByteString to String.
(cherry picked from commit 84a7fead0eefd967d4319f4d71c0a0ca3095d2d1)
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)
This also fixes a bug where task IDs were being deallocated from the
wrong IDAllocator. I don't know if it was actually possible to cause any
real trouble with that mistake, nor do I know how to write a test for
it, but this makes the bug go away.
(cherry picked from commit 08d60d7521915b4f73fd3bb40a1aa159f4f31eb1)
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
The Response interface of the Fetch API can now parse form urlencoded
bodies when Content-Type is set to 'application/x-www-form-urlencoded'.
(cherry picked from commit b8fa572c6742c0f1f63da0f63c8b86835a86988d)
They are now blocked on pages which:
- Don't have an opaque origin (should be only user-initiated or about:)
- Aren't other file: pages
- Aren't other resource: pages
(cherry picked from commit 1f3285eb0410ff5c902e148932205d9e4b7fbd9b)
Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...>
everywhere, we now encapsulate this in a class.
Even better, the new class also allows keeping track of multiple headers
with the same name! This will make it possible for HTTP responses to
actually retain all their headers on the perilous journey from
RequestServer to LibWeb.
(cherry picked from commit e636851481eabdf00953573a5eb459ee52feeacc)
Updated various SerenityOS components to make it build.
Fetch: Make sure we iterate over HeaderMap's headers()
This fixes a build failure when built with CMake option
'-DENABLE_ALL_THE_DEBUG_MACROS=ON'.
(cherry picked from commit c51d01bea712d75f9b2cd700be942935044e49b4)
Supporting unbuffered fetches is actually part of the fetch spec in its
HTTP-network-fetch algorithm. We had previously implemented this method
in a very ad-hoc manner as a simple wrapper around ResourceLoader. This
is still the case, but we now implement a good amount of these steps
according to spec, using ResourceLoader's unbuffered API. The response
data is forwarded through to the fetch response using streams.
This will eventually let us remove the use of ResourceLoader's buffered
API, as all responses should just be streamed this way. The streams spec
then supplies ways to wait for completion, thus allowing fully buffered
responses. However, we have more work to do to make the other parts of
our fetch implementation (namely, Body::fully_read) use streams before
we can do this.
This callback is meant to be triggered by streams, which does not always
provide a WebIDL::DOMException. Pass a plain value instead. Of all the
users of this callback, only one actually uses the value, and already
converts the DOMException to a plain value.
Performing a lookup in the blob URL registry does not work in the case
of a web worker - as the registry is not shared between processes.
However - the URL itself passed to a worker has the blob attached to it,
which we can pull out of the URL on a fetch.
