We currently store Web::Fetch::Infrastructure::Response objects in the
HTTP cache. They are associated with their original realm, but when we
use a cached response, we clone it into the target realm. For example,
two <iframe> objects loading the same HTML will be in different realms.
When we clone the response, we must use the target realm throughout the
entire cloning process. We neglected to do this for the cloned response
body stream, which is cloned via teeing. The result was the the stream
for the "cloned" response was created in the original realm, causing
issues down the line when reading from that stream tried to handle read
promises on behalf of the original realm. There are protections in place
to prevent this from happening, and the cached response read would never
complete.
These are not associated with a javascript realm, so to avoid
confusion about which realm these need to be created in, make
all of these objects a GC::Cell, and deal with the fallout.
JavaScript module requests (in a non-worker context) always have CORS
enabled. However, CORS requests are only allowed for same-origin or
HTTP/S requests. This patch extends this to allow resource:// requests
from opaque origins (e.g. about: URLs).
We must also set the Access-Control-Allow-Origin header to "null" to
ensure that the response is accepted by the CORS checks. This does not
affect requesting resource:// URLs from resource:// URLs as those are
same-origin and skip CORS checks.
This ultimately enables requesting resource:// JS modules from the
about:settings page.
Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
This will cause an exception to be thrown if user attempts to read from
the response stream of a failed request.
This is unfortunately not testable in CI. It requires a network response
(i.e. not a file:// URL). We also cannot import relevant WPT tests; they
exercise this condition with a python-generated response.
The main streams AO file has gotten very large, and is a bit difficult
to navigate. In an effort to improve DX, this migrates TransformStream
AOs to their own file.
The main streams AO file has gotten very large, and is a bit difficult
to navigate. In an effort to improve DX, this migrates ReadableStream
AOs to their own file. And the helper classes used for the tee and pipe-
to operations are also in their own files.
This will be needed by Streams. To support this, we now store callbacks
in a hash table, keyed by an ID. Callers may use that ID to remove the
callback at a later point.
This is very clearly a very dangerous API to have, and was causing
a crash on Linux as a result of a stack use-after-free when visiting
https://www.index.hr/.
Fixes#3901
This is required to store Content Security Policies, as their
Directives are implemented as subclasses with overridden virtual
functions. Thus, they cannot be stored as generic Directive classes, as
it'll lose the ability to call overridden functions when they are
copied.
This patch synchronizes changes from whatwg/fetch#1569 and
resolves a related FIXME: "Refactor this to the new version of the
spec introduced with whatwg/fetch@464326e.”
This currently uses a non spec-compliant property on the Response
object, which represents the time that the Response was created.
Setting this value allows `Performance.timeOrigin` to return a
reasonable value.
Instead of just putting in members directly, wrap them up in structs
which represent what a URL blob entry is meant to hold per the spec.
This makes more obvious what this is meant to represent, such as the
ByteBuffer being used to represent the bytes behind a Blob.
This also allows us to use a stronger type for a function that needs
to return a Blob URL entry's object.
This mistakenly implemented the 'piped to' operation on ReadableStream.
No functional difference as the caller was doing the extra work already
of 'piped through' vs 'piped to'.
Otherwise we will fully read from the cached response and invalidate
it's stream, invalidating it for the next time it is read from. Fixes
a crash when reloading linegoup.lol after two reloads.
One day we'll have an eviction strategy, too, but for now let's not
allow these to get collected.
Co-Authored-By: Gingeh <39150378+Gingeh@users.noreply.github.com>
isomorphic encoding a value that has already been encoded will
result in garbage data. `response_headers` is already encoded in
ISO-8859-1/latin1, we cannot use `from_string_pair`, as it triggers
ISO-8859-1/latin1 encoding.
Follow-up of https://github.com/LadybirdBrowser/ladybird/pull/1893
This patch ensure Headers object's associated header list
is ISO-8859-1 encoded when set using `Infra::isomorphic_encode`,
and correctly decoded using `Infra::isomorphic_decode`.
Follow-up of https://github.com/LadybirdBrowser/ladybird/pull/1893
By actually using streams, they get marked as disturbed and the
`.bodyUsed` API starts to work. Fixes at least 94 subtests in the WPT
`fetch/api/request` test suite.
Co-authored-by: Timothy Flynn <trflynn89@pm.me>
