Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Fetch/Infrastructure/HTTP/Bodies.cpp

142 lines
6.2 KiB
C++
Raw Normal View History

LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
/*
LibWeb/Fetch: Port infrastructure to new String
2023-03-02 23:26:35 +00:00
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
* Copyright (c) 2024, Jelle Raaijmakers <jelle@ladybird.org>
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Move PromiseCapability into its own cpp/h file This is not strictly connected to PromiseReaction in any way. Preparation before doing some actual work on it :^)
2022-10-02 10:59:22 +01:00
#include <LibJS/Runtime/PromiseCapability.h>
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
#include <LibWeb/Bindings/ExceptionOrUtils.h>
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
#include <LibWeb/Bindings/MainThreadVM.h>
LibWeb: Implement 'Byte sequence as body' AO
2022-10-30 14:39:32 +00:00
#include <LibWeb/Fetch/BodyInit.h>
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
#include <LibWeb/Fetch/Infrastructure/HTTP/Bodies.h>
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
#include <LibWeb/Fetch/Infrastructure/IncrementalReadLoopReadRequest.h>
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
#include <LibWeb/Fetch/Infrastructure/Task.h>
LibWeb: Implement a slightly better ad-hoc Body::clone method Just creating a stream on the JS heap isn't enough, as we will later crash when trying to read from that stream as it hasn't been properly initialized. Instead, until we have teeing implemented (which is a rather huge part of the Streams spec), create streams using proper AOs that do initialize the stream.
2024-01-27 09:16:09 -05:00
#include <LibWeb/HTML/Scripting/TemporaryExecutionContext.h>
#include <LibWeb/Streams/AbstractOperations.h>
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
LibWeb: Move Fetch infra into the Web::Fetch::Infrastructure namespace The Fetch spec unfortunately will cause a name clash between the Request concept and the Request JS object - both cannot live in the Web::Fetch namespace, and WrapperGenerator generally assumes `Web::<Name>` for things living in the `<Name>/` subdirectory, so let's instead move infra code into its own namespace - it already sits in a (sub-)subdirectory anyway.
2022-07-17 23:52:02 +01:00
namespace Web::Fetch::Infrastructure {
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
GC_DEFINE_ALLOCATOR(Body);
LibWeb: Put most LibWeb GC objects in type-specific heap blocks With this change, we now have ~1200 CellAllocators across both LibJS and LibWeb in a normal WebContent instance. This gives us a minimum heap size of 4.7 MiB in the scenario where we only have one cell allocated per type. Of course, in practice there will be many more of each type, so the effective overhead is quite a bit smaller than that in practice. I left a few types unconverted to this mechanism because I got tired of doing this. :^)
2023-11-19 19:47:52 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
GC::Ref<Body> Body::create(JS::VM& vm, GC::Ref<Streams::ReadableStream> stream)
LibWeb: Make `Fetch::Infrastructure::Body` be GC allocated Making the body GC-allocated allows us to avoid using `JS::Handle` for `m_stream` in its members.
2023-08-18 19:38:13 +02:00
{
LibJS+LibWeb: Rename Heap::allocate_without_realm to Heap::allocate Now that the heap has no knowledge about a JavaScript realm and is purely for managing the memory of the heap, it does not make sense to name this function to say that it is a non-realm variant.
2024-11-14 06:13:46 +13:00
return vm.heap().allocate<Body>(stream);
LibWeb: Make `Fetch::Infrastructure::Body` be GC allocated Making the body GC-allocated allows us to avoid using `JS::Handle` for `m_stream` in its members.
2023-08-18 19:38:13 +02:00
}
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
GC::Ref<Body> Body::create(JS::VM& vm, GC::Ref<Streams::ReadableStream> stream, SourceType source, Optional<u64> length)
LibWeb: Make `Fetch::Infrastructure::Body` be GC allocated Making the body GC-allocated allows us to avoid using `JS::Handle` for `m_stream` in its members.
2023-08-18 19:38:13 +02:00
{
LibJS+LibWeb: Rename Heap::allocate_without_realm to Heap::allocate Now that the heap has no knowledge about a JavaScript realm and is purely for managing the memory of the heap, it does not make sense to name this function to say that it is a non-realm variant.
2024-11-14 06:13:46 +13:00
return vm.heap().allocate<Body>(stream, source, length);
LibWeb: Make `Fetch::Infrastructure::Body` be GC allocated Making the body GC-allocated allows us to avoid using `JS::Handle` for `m_stream` in its members.
2023-08-18 19:38:13 +02:00
}
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
Body::Body(GC::Ref<Streams::ReadableStream> stream)
LibWeb: Remove ReadableStreamDummy in favor of ReadableStream
2022-09-21 23:54:04 +01:00
: m_stream(move(stream))
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
{
}
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
Body::Body(GC::Ref<Streams::ReadableStream> stream, SourceType source, Optional<u64> length)
LibWeb: Remove ReadableStreamDummy in favor of ReadableStream
2022-09-21 23:54:04 +01:00
: m_stream(move(stream))
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
, m_source(move(source))
, m_length(move(length))
{
}
LibWeb: Make `Fetch::Infrastructure::Body` be GC allocated Making the body GC-allocated allows us to avoid using `JS::Handle` for `m_stream` in its members.
2023-08-18 19:38:13 +02:00
void Body::visit_edges(Cell::Visitor& visitor)
{
Base::visit_edges(visitor);
visitor.visit(m_stream);
}
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
// https://fetch.spec.whatwg.org/#concept-body-clone
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
GC::Ref<Body> Body::clone(JS::Realm& realm)
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
{
LibWeb: Make TemporaryExecutionContext take a Realm&
2024-10-24 20:39:18 +13:00
HTML::TemporaryExecutionContext execution_context { realm, HTML::TemporaryExecutionContext::CallbacksEnabled::Yes };
LibWeb: Implement a slightly better ad-hoc Body::clone method Just creating a stream on the JS heap isn't enough, as we will later crash when trying to read from that stream as it hasn't been properly initialized. Instead, until we have teeing implemented (which is a rather huge part of the Streams spec), create streams using proper AOs that do initialize the stream.
2024-01-27 09:16:09 -05:00
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
// To clone a body body, run these steps:
LibWeb: Use the stream teeing methods for cloning Fetch response bodies
2024-01-28 14:21:32 -05:00
// 1. Let « out1, out2 » be the result of teeing body’s stream.
auto [out1, out2] = m_stream->tee().release_value_but_fixme_should_propagate_errors();
LibWeb: Implement a slightly better ad-hoc Body::clone method Just creating a stream on the JS heap isn't enough, as we will later crash when trying to read from that stream as it hasn't been properly initialized. Instead, until we have teeing implemented (which is a rather huge part of the Streams spec), create streams using proper AOs that do initialize the stream.
2024-01-27 09:16:09 -05:00
LibWeb: Use the stream teeing methods for cloning Fetch response bodies
2024-01-28 14:21:32 -05:00
// 2. Set body’s stream to out1.
m_stream = out1;
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
// 3. Return a body whose stream is out2 and other members are copied from body.
LibWeb: Implement a slightly better ad-hoc Body::clone method Just creating a stream on the JS heap isn't enough, as we will later crash when trying to read from that stream as it hasn't been properly initialized. Instead, until we have teeing implemented (which is a rather huge part of the Streams spec), create streams using proper AOs that do initialize the stream.
2024-01-27 09:16:09 -05:00
return Body::create(realm.vm(), *out2, m_source, m_length);
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
}
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
// https://fetch.spec.whatwg.org/#body-fully-read
LibWeb: Propagate OOM in Body::fully_read() through its error callback Fetched bodies can be on the order of gigabytes, so rather than crashing when we hit OOM here, we can simply invoke the error callback with a DOM exception. We use "UnknownError" here as the spec directly supports this for OOM errors: UnknownError: The operation failed for an unknown transient reason (e.g. out of memory). This is still an ad-hoc implementation. We should be using streams, and we do have the AOs available to do so. But they need to be massaged to be compatible with callers of Body::fully_read. And once we do use streams, this function will become infallible - so making it infallible here is at least a step in the right direction.
2024-04-26 14:57:40 -04:00
void Body::fully_read(JS::Realm& realm, Web::Fetch::Infrastructure::Body::ProcessBodyCallback process_body, Web::Fetch::Infrastructure::Body::ProcessBodyErrorCallback process_body_error, TaskDestination task_destination) const
LibWeb: Stub out Fetch::Infrastructure::Body::fully_read_as_promise()
2022-09-25 19:27:02 +01:00
{
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
HTML::TemporaryExecutionContext execution_context { realm, HTML::TemporaryExecutionContext::CallbacksEnabled::Yes };
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
// FIXME: 1. If taskDestination is null, then set taskDestination to the result of starting a new parallel queue.
// FIXME: Handle 'parallel queue' task destination
VERIFY(!task_destination.has<Empty>());
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
auto task_destination_object = task_destination.get<GC::Ref<JS::Object>>();
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
// 2. Let successSteps given a byte sequence bytes be to queue a fetch task to run processBody given bytes, with taskDestination.
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
auto success_steps = [&realm, process_body, task_destination_object](ByteBuffer bytes) {
queue_fetch_task(*task_destination_object, GC::create_function(realm.heap(), [process_body, bytes = move(bytes)]() mutable {
process_body->function()(move(bytes));
LibWeb: Let queue_fetch_task() take a JS::HeapFunction Changes the signature of queue_fetch_task() from AK:Function to JS::HeapFunction to be more clear to the user of the function that this is what it uses internally.
2024-04-19 10:23:40 +02:00
}));
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
};
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
// 3. Let errorSteps optionally given an exception exception be to queue a fetch task to run processBodyError given
// exception, with taskDestination.
auto error_steps = [&realm, process_body_error, task_destination_object](JS::Value exception) {
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
queue_fetch_task(*task_destination_object, GC::create_function(realm.heap(), [process_body_error, exception]() {
LibWeb: Change Fetch's ProcessBodyError to accept a plain JS value 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.
2024-04-30 07:20:41 -04:00
process_body_error->function()(exception);
LibWeb: Let queue_fetch_task() take a JS::HeapFunction Changes the signature of queue_fetch_task() from AK:Function to JS::HeapFunction to be more clear to the user of the function that this is what it uses internally.
2024-04-19 10:23:40 +02:00
}));
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
};
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
// 4. Let reader be the result of getting a reader for body’s stream. If that threw an exception, then run errorSteps
// with that exception and return.
LibWeb: Add a 'get a reader' helper method on ReadableStream
2024-12-24 12:38:25 +13:00
auto reader = m_stream->get_a_reader();
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
if (reader.is_exception()) {
LibWeb: Remove `dom_` from `dom_exception_to_throw_completion` We're not converting `WebIDL::DOMException`, but `WebIDL::Exception` instead.
2024-11-04 14:37:27 +01:00
auto throw_completion = Bindings::exception_to_throw_completion(realm.vm(), reader.release_error());
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
error_steps(throw_completion.release_value().value());
return;
}
LibWeb/Fetch: Implement Body's "fully read" function from the spec Required by XHR's reliance on Fetch.
2023-02-28 18:12:44 +00:00
// 5. Read all bytes from reader, given successSteps and errorSteps.
LibWeb: Implement Web::Fetch::Body::fully_read() closer to spec 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>
2024-11-04 14:11:07 +01:00
reader.value()->read_all_bytes(GC::create_function(realm.heap(), move(success_steps)), GC::create_function(realm.heap(), move(error_steps)));
LibWeb: Stub out Fetch::Infrastructure::Body::fully_read_as_promise()
2022-09-25 19:27:02 +01:00
}
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
// https://fetch.spec.whatwg.org/#body-incrementally-read
void Body::incrementally_read(ProcessBodyChunkCallback process_body_chunk, ProcessEndOfBodyCallback process_end_of_body, ProcessBodyErrorCallback process_body_error, TaskDestination task_destination)
{
LibWeb: Make TemporaryExecutionContext take a Realm&
2024-10-24 20:39:18 +13:00
HTML::TemporaryExecutionContext const execution_context { m_stream->realm(), HTML::TemporaryExecutionContext::CallbacksEnabled::Yes };
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
VERIFY(task_destination.has<GC::Ref<JS::Object>>());
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
// FIXME: 1. If taskDestination is null, then set taskDestination to the result of starting a new parallel queue.
// FIXME: Handle 'parallel queue' task destination
// 2. Let reader be the result of getting a reader for body’s stream.
// NOTE: This operation will not throw an exception.
LibWeb: Add a 'get a reader' helper method on ReadableStream
2024-12-24 12:38:25 +13:00
auto reader = MUST(m_stream->get_a_reader());
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
// 3. Perform the incrementally-read loop given reader, taskDestination, processBodyChunk, processEndOfBody, and processBodyError.
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
incrementally_read_loop(reader, task_destination.get<GC::Ref<JS::Object>>(), process_body_chunk, process_end_of_body, process_body_error);
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
}
// https://fetch.spec.whatwg.org/#incrementally-read-loop
LibGC+Everywhere: Factor out a LibGC from LibJS 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
2024-11-15 04:01:23 +13:00
void Body::incrementally_read_loop(Streams::ReadableStreamDefaultReader& reader, GC::Ref<JS::Object> task_destination, ProcessBodyChunkCallback process_body_chunk, ProcessEndOfBodyCallback process_end_of_body, ProcessBodyErrorCallback process_body_error)
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
{
auto& realm = reader.realm();
// 1. Let readRequest be the following read request:
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> 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.
2024-11-14 05:50:17 +13:00
auto read_request = realm.create<IncrementalReadLoopReadRequest>(*this, reader, task_destination, process_body_chunk, process_end_of_body, process_body_error);
LibWeb: Implement the concept incrementally read a body
2024-05-17 22:06:27 +02:00
// 2. Read a chunk from reader given readRequest.
reader.read_a_chunk(read_request);
}
LibWeb: Implement 'Byte sequence as body' AO
2022-10-30 14:39:32 +00:00
// https://fetch.spec.whatwg.org/#byte-sequence-as-a-body
LibWeb: Remove exception handling from safely extracting response bodies The entire purpose of this AO is to avoid handling exceptions, which we can do now that the underlying AOs do not throw exceptions on OOM.
2024-11-04 16:06:01 +01:00
GC::Ref<Body> byte_sequence_as_body(JS::Realm& realm, ReadonlyBytes bytes)
LibWeb: Implement 'Byte sequence as body' AO
2022-10-30 14:39:32 +00:00
{
// To get a byte sequence bytes as a body, return the body of the result of safely extracting bytes.
LibWeb: Remove exception handling from safely extracting response bodies The entire purpose of this AO is to avoid handling exceptions, which we can do now that the underlying AOs do not throw exceptions on OOM.
2024-11-04 16:06:01 +01:00
auto [body, _] = safely_extract_body(realm, bytes);
LibWeb: Implement 'Byte sequence as body' AO
2022-10-30 14:39:32 +00:00
return body;
}
LibWeb: Add definitions from '2.2.4. Bodies' in the Fetch spec ...at least the ones that don't require an implementation of the Streams spec :^)
2022-07-12 18:04:24 +01:00
}
Reference in a new issue Copy permalink