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

115 lines
5 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: 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: 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/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: Stub out Fetch::Infrastructure::Body::fully_read_as_promise()
2022-09-25 19:27:02 +01:00
#include <LibWeb/WebIDL/Promise.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
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
JS_DEFINE_ALLOCATOR(Body);
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
JS::NonnullGCPtr<Body> Body::create(JS::VM& vm, JS::NonnullGCPtr<Streams::ReadableStream> stream)
{
return vm.heap().allocate_without_realm<Body>(stream);
}
JS::NonnullGCPtr<Body> Body::create(JS::VM& vm, JS::NonnullGCPtr<Streams::ReadableStream> stream, SourceType source, Optional<u64> length)
{
return vm.heap().allocate_without_realm<Body>(stream, source, length);
}
Body::Body(JS::NonnullGCPtr<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
{
}
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
Body::Body(JS::NonnullGCPtr<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
LibWeb: Use the stream teeing methods for cloning Fetch response bodies
2024-01-28 14:21:32 -05:00
JS::NonnullGCPtr<Body> Body::clone(JS::Realm& realm)
LibWeb: Stub out Fetch::Infrastructure::Body::clone()
2022-09-25 19:25:53 +01:00
{
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
HTML::TemporaryExecutionContext execution_context { Bindings::host_defined_environment_settings_object(realm), HTML::TemporaryExecutionContext::CallbacksEnabled::Yes };
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/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>());
auto task_destination_object = task_destination.get<JS::NonnullGCPtr<JS::Object>>();
// 2. Let successSteps given a byte sequence bytes be to queue a fetch task to run processBody given bytes, with taskDestination.
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
auto success_steps = [&realm, process_body, task_destination_object = task_destination_object](ReadonlyBytes bytes) -> ErrorOr<void> {
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
// Make a copy of the bytes, as the source of the bytes may disappear between the time the task is queued and executed.
auto bytes_copy = TRY(ByteBuffer::copy(bytes));
LibWeb: Mark the task in the success steps of reading a body as mutable Otherwise, the `move(bytes_copy)` in the body of the steps does not actually act as a `move`.
2024-04-26 14:14:18 -04:00
queue_fetch_task(*task_destination_object, JS::create_heap_function(realm.heap(), [process_body, bytes_copy = move(bytes_copy)]() mutable {
LibWeb: Fix GC leaks in Fetch::Infrastructure::Body::fully_read() By making this function accept the success and error steps as HeapFunction rather than SafeFunction, we break a bunch of strong GC cycles.
2024-04-23 10:25:20 +02:00
process_body->function()(move(bytes_copy));
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
return {};
};
LibWeb: Make `processBodyError` take an optional exception Changed here: https://github.com/whatwg/fetch/commit/018ac19838ade92324a1900113636a8bf98f3a1b
2023-05-13 12:44:46 +01:00
// 3. Let errorSteps optionally given an exception exception be to queue a fetch task to run processBodyError given exception, with taskDestination.
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
auto error_steps = [&realm, process_body_error, task_destination_object](JS::GCPtr<WebIDL::DOMException> exception) {
queue_fetch_task(*task_destination_object, JS::create_heap_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
};
// 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.
// 5. Read all bytes from reader, given successSteps and errorSteps.
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
// FIXME: Use streams for these steps.
m_source.visit(
[&](ByteBuffer const& byte_buffer) {
if (auto result = success_steps(byte_buffer); result.is_error())
error_steps(WebIDL::UnknownError::create(realm, "Out-of-memory"_fly_string));
},
[&](JS::Handle<FileAPI::Blob> const& blob) {
if (auto result = success_steps(blob->bytes()); result.is_error())
error_steps(WebIDL::UnknownError::create(realm, "Out-of-memory"_fly_string));
},
[&](Empty) {
error_steps(WebIDL::DOMException::create(realm, "DOMException"_fly_string, "Reading from Blob, FormData or null source is not yet implemented"_fly_string));
});
LibWeb: Stub out Fetch::Infrastructure::Body::fully_read_as_promise()
2022-09-25 19:27:02 +01:00
}
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: 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
WebIDL::ExceptionOr<JS::NonnullGCPtr<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.
auto [body, _] = TRY(safely_extract_body(realm, bytes));
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