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
In particular, the processBody callback here *can't* move the
processBodyError callback. It is needed a few lines after. Passing by
value is safe and intended here.
This lets us move a few Host-related functions (like serialization and
checks for what the Host is) into Host instead of having them dotted
around the codebase.
For now, the interface is still very Variant-like, to avoid having to
change quite so much in one go.
A couple of reasons:
- Origin's Host (when in the tuple state) can't be null
- There's an "empty host" concept in the spec which is NOT the same as a
null Host, and that was confusing me.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
