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

328 lines
15 KiB
C
Raw Normal View History

LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +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.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/ByteBuffer.h>
#include <AK/Error.h>
#include <AK/Forward.h>
#include <AK/Optional.h>
LibWeb/Fetch: Add freshness notion to HTTP::Response Defined in RFC9111 "HTTP Caching". Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-03-23 22:16:15 -04:00
#include <AK/Time.h>
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
#include <AK/Vector.h>
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
#include <LibJS/Forward.h>
#include <LibJS/Heap/Cell.h>
LibWeb: Add missing GCPtr.h includes to Fetch headers These are missing in most Fetch headers, and clangd is (rightfully) very loud about it on a few of these.
2023-02-10 08:29:14 -05:00
#include <LibJS/Heap/GCPtr.h>
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
#include <LibURL/URL.h>
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
#include <LibWeb/Fetch/Infrastructure/HTTP/Bodies.h>
#include <LibWeb/Fetch/Infrastructure/HTTP/Headers.h>
#include <LibWeb/Fetch/Infrastructure/HTTP/Statuses.h>
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.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
// https://fetch.spec.whatwg.org/#concept-response
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
class Response : public JS::Cell {
JS_CELL(Response, JS::Cell);
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_DECLARE_ALLOCATOR(Response);
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
public:
enum class CacheState {
Local,
Validated,
};
enum class Type {
Basic,
CORS,
Default,
Error,
Opaque,
OpaqueRedirect,
};
// https://fetch.spec.whatwg.org/#response-body-info
struct BodyInfo {
// https://fetch.spec.whatwg.org/#fetch-timing-info-encoded-body-size
u64 encoded_size { 0 };
// https://fetch.spec.whatwg.org/#fetch-timing-info-decoded-body-size
u64 decoded_size { 0 };
LibWeb/Fetch: Align `is_network_error()` with the latest specification
2023-10-02 19:30:44 +02:00
LibWeb/Fetch: Expose a minimised Content-Type to Resource Timing See: - https://github.com/whatwg/fetch/commit/931cd06
2024-05-19 13:23:38 +01:00
// https://fetch.spec.whatwg.org/#response-body-info-content-type
String content_type {};
LibWeb/Fetch: Align `is_network_error()` with the latest specification
2023-10-02 19:30:44 +02:00
bool operator==(BodyInfo const&) const = default;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] static JS::NonnullGCPtr<Response> create(JS::VM&);
LibWeb/Fetch: Store Response error message as a String{,View} variant The majority of error strings are StringView literals, and it seems silly to require heap-allocating strings for these. This idea is stolen from a recent change in fd1fbad :^)
2023-03-03 18:02:43 +00:00
[[nodiscard]] static JS::NonnullGCPtr<Response> aborted_network_error(JS::VM&);
[[nodiscard]] static JS::NonnullGCPtr<Response> network_error(JS::VM&, Variant<String, StringView> message);
[[nodiscard]] static JS::NonnullGCPtr<Response> appropriate_network_error(JS::VM&, FetchParams const&);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
virtual ~Response() = default;
[[nodiscard]] virtual Type type() const { return m_type; }
void set_type(Type type) { m_type = type; }
[[nodiscard]] virtual bool aborted() const { return m_aborted; }
void set_aborted(bool aborted) { m_aborted = aborted; }
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
[[nodiscard]] virtual Vector<URL::URL> const& url_list() const { return m_url_list; }
[[nodiscard]] virtual Vector<URL::URL>& url_list() { return m_url_list; }
void set_url_list(Vector<URL::URL> url_list) { m_url_list = move(url_list); }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Status status() const { return m_status; }
void set_status(Status status) { m_status = status; }
[[nodiscard]] virtual ReadonlyBytes status_message() const { return m_status_message; }
void set_status_message(ByteBuffer status_message) { m_status_message = move(status_message); }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] virtual JS::NonnullGCPtr<HeaderList> header_list() const { return m_header_list; }
void set_header_list(JS::NonnullGCPtr<HeaderList> header_list) { m_header_list = header_list; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +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
[[nodiscard]] virtual JS::GCPtr<Body> const& body() const { return m_body; }
[[nodiscard]] virtual JS::GCPtr<Body>& body() { return m_body; }
void set_body(JS::GCPtr<Body> body) { m_body = move(body); }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Optional<CacheState> const& cache_state() const { return m_cache_state; }
void set_cache_state(Optional<CacheState> cache_state) { m_cache_state = move(cache_state); }
[[nodiscard]] virtual Vector<ByteBuffer> const& cors_exposed_header_name_list() const { return m_cors_exposed_header_name_list; }
void set_cors_exposed_header_name_list(Vector<ByteBuffer> cors_exposed_header_name_list) { m_cors_exposed_header_name_list = move(cors_exposed_header_name_list); }
[[nodiscard]] virtual bool range_requested() const { return m_range_requested; }
void set_range_requested(bool range_requested) { m_range_requested = range_requested; }
[[nodiscard]] virtual bool request_includes_credentials() const { return m_request_includes_credentials; }
void set_request_includes_credentials(bool request_includes_credentials) { m_request_includes_credentials = request_includes_credentials; }
[[nodiscard]] virtual bool timing_allow_passed() const { return m_timing_allow_passed; }
void set_timing_allow_passed(bool timing_allow_passed) { m_timing_allow_passed = timing_allow_passed; }
[[nodiscard]] virtual BodyInfo const& body_info() const { return m_body_info; }
void set_body_info(BodyInfo body_info) { m_body_info = body_info; }
LibWeb: Add has-cross-origin-redirects flag to Fetch::Infra::Response This is a change in the Fetch spec. See: https://github.com/whatwg/fetch/commit/7c30987
2022-10-30 14:40:23 +00:00
[[nodiscard]] bool has_cross_origin_redirects() const { return m_has_cross_origin_redirects; }
void set_has_cross_origin_redirects(bool has_cross_origin_redirects) { m_has_cross_origin_redirects = has_cross_origin_redirects; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] bool is_aborted_network_error() const;
[[nodiscard]] bool is_network_error() const;
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
[[nodiscard]] Optional<URL::URL const&> url() const;
[[nodiscard]] ErrorOr<Optional<URL::URL>> location_url(Optional<String> const& request_fragment) const;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
LibWeb: Remove OOM propagation from Fetch::Infrastructure::Responses
2024-04-26 13:42:39 -04:00
[[nodiscard]] JS::NonnullGCPtr<Response> clone(JS::Realm&) const;
LibWeb: Make Fetch::Infrastructure::{Request,Response} ref-counted With the addition of the 'fetch params' struct, the single ownership model we had so far falls apart completely. Additionally, this works nicely for FilteredResponse's internal response instead of risking a dangling reference. Replacing the public constructor with a create() function also found a few instances of a Request being stack-allocated!
2022-10-04 23:45:47 +01:00
LibWeb: Implement the fetch response's unsafe response AO
2023-05-10 16:57:23 -04:00
[[nodiscard]] JS::NonnullGCPtr<Response> unsafe_response();
LibWeb: Implement the fetch response is CORS-cross-origin AO
2023-05-10 16:27:55 -04:00
[[nodiscard]] bool is_cors_cross_origin() const;
LibWeb/Fetch: Add freshness notion to HTTP::Response Defined in RFC9111 "HTTP Caching". Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-03-23 22:16:15 -04:00
[[nodiscard]] bool is_fresh() const;
[[nodiscard]] bool is_stale_while_revalidate() const;
[[nodiscard]] bool is_stale() const;
LibWeb: Require error message for Response::network_error() There will be a lot of different cases where we'll return an error response, and having a customized Promise rejection message seems quite useful. Note that this has to be distinct from the existing 'status message', which is required to be empty in those cases.
2022-10-23 19:10:17 +02:00
// Non-standard
LibWeb/Fetch: Store Response error message as a String{,View} variant The majority of error strings are StringView literals, and it seems silly to require heap-allocating strings for these. This idea is stolen from a recent change in fd1fbad :^)
2023-03-03 18:02:43 +00:00
[[nodiscard]] Optional<StringView> network_error_message() const;
LibWeb: Require error message for Response::network_error() There will be a lot of different cases where we'll return an error response, and having a customized Promise rejection message seems quite useful. Note that this has to be distinct from the existing 'status message', which is required to be empty in those cases.
2022-10-23 19:10:17 +02:00
LibWeb: Make Fetch::Infrastructure::{Request,Response} ref-counted With the addition of the 'fetch params' struct, the single ownership model we had so far falls apart completely. Additionally, this works nicely for FilteredResponse's internal response instead of risking a dangling reference. Replacing the public constructor with a create() function also found a few instances of a Request being stack-allocated!
2022-10-04 23:45:47 +01:00
protected:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
explicit Response(JS::NonnullGCPtr<HeaderList>);
virtual void visit_edges(JS::Cell::Visitor&) override;
LibWeb: Implement Fetch::Infrastructure::Response::clone()
2022-09-25 19:23:35 +01:00
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
private:
// https://fetch.spec.whatwg.org/#concept-response-type
// A response has an associated type which is "basic", "cors", "default", "error", "opaque", or "opaqueredirect". Unless stated otherwise, it is "default".
Type m_type { Type::Default };
// https://fetch.spec.whatwg.org/#concept-response-aborted
// A response can have an associated aborted flag, which is initially unset.
bool m_aborted { false };
LibWeb: Add missing link to Fetch::Infrastructure::Response member
2022-10-04 23:42:21 +01:00
// https://fetch.spec.whatwg.org/#concept-response-url-list
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
// A response has an associated URL list (a list of zero or more URLs). Unless stated otherwise, it is the empty list.
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
Vector<URL::URL> m_url_list;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
// https://fetch.spec.whatwg.org/#concept-response-status
// A response has an associated status, which is a status. Unless stated otherwise it is 200.
Status m_status { 200 };
// https://fetch.spec.whatwg.org/#concept-response-status-message
// A response has an associated status message. Unless stated otherwise it is the empty byte sequence.
ByteBuffer m_status_message;
// https://fetch.spec.whatwg.org/#concept-response-header-list
// A response has an associated header list (a header list). Unless stated otherwise it is empty.
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS::NonnullGCPtr<HeaderList> m_header_list;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
// https://fetch.spec.whatwg.org/#concept-response-body
// A response has an associated body (null or a body). Unless stated otherwise it is null.
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::GCPtr<Body> m_body;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
// https://fetch.spec.whatwg.org/#concept-response-cache-state
// A response has an associated cache state (the empty string, "local", or "validated"). Unless stated otherwise, it is the empty string.
Optional<CacheState> m_cache_state;
// https://fetch.spec.whatwg.org/#concept-response-cors-exposed-header-name-list
// A response has an associated CORS-exposed header-name list (a list of zero or more header names). The list is empty unless otherwise specified.
Vector<ByteBuffer> m_cors_exposed_header_name_list;
// https://fetch.spec.whatwg.org/#concept-response-range-requested-flag
// A response has an associated range-requested flag, which is initially unset.
bool m_range_requested { false };
// https://fetch.spec.whatwg.org/#response-request-includes-credentials
// A response has an associated request-includes-credentials (a boolean), which is initially true.
bool m_request_includes_credentials { true };
// https://fetch.spec.whatwg.org/#concept-response-timing-allow-passed
// A response has an associated timing allow passed flag, which is initially unset.
bool m_timing_allow_passed { false };
// https://fetch.spec.whatwg.org/#concept-response-body-info
// A response has an associated body info (a response body info). Unless stated otherwise, it is a new response body info.
BodyInfo m_body_info;
// https://fetch.spec.whatwg.org/#response-service-worker-timing-info
// FIXME: A response has an associated service worker timing info (null or a service worker timing info), which is initially null.
LibWeb: Add has-cross-origin-redirects flag to Fetch::Infra::Response This is a change in the Fetch spec. See: https://github.com/whatwg/fetch/commit/7c30987
2022-10-30 14:40:23 +00:00
// https://fetch.spec.whatwg.org/#response-has-cross-origin-redirects
// A response has an associated has-cross-origin-redirects (a boolean), which is initially false.
bool m_has_cross_origin_redirects { false };
LibWeb: Require error message for Response::network_error() There will be a lot of different cases where we'll return an error response, and having a customized Promise rejection message seems quite useful. Note that this has to be distinct from the existing 'status message', which is required to be empty in those cases.
2022-10-23 19:10:17 +02:00
LibWeb/Fetch: Add freshness notion to HTTP::Response Defined in RFC9111 "HTTP Caching". Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-03-23 22:16:15 -04:00
// FIXME is the type correct?
u64 current_age() const;
u64 freshness_lifetime() const;
u64 stale_while_revalidate_lifetime() const;
LibWeb: Require error message for Response::network_error() There will be a lot of different cases where we'll return an error response, and having a customized Promise rejection message seems quite useful. Note that this has to be distinct from the existing 'status message', which is required to be empty in those cases.
2022-10-23 19:10:17 +02:00
// Non-standard
LibWeb/Fetch: Add freshness notion to HTTP::Response Defined in RFC9111 "HTTP Caching". Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-03-23 22:16:15 -04:00
UnixDateTime m_response_time;
LibWeb/Fetch: Store Response error message as a String{,View} variant The majority of error strings are StringView literals, and it seems silly to require heap-allocating strings for these. This idea is stolen from a recent change in fd1fbad :^)
2023-03-03 18:02:43 +00:00
Optional<Variant<String, StringView>> m_network_error_message;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
// https://fetch.spec.whatwg.org/#concept-filtered-response
LibWeb: Heap-allocate returned Fetch::Infrastructure::{Request,Response} A Request/Response instance should always be heap-allocated and have clear ownership, so let's also wrap it in a NonnullOwnPtr instead of putting them on the stack.
2022-09-24 00:28:11 +01:00
class FilteredResponse : public Response {
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS_CELL(FilteredResponse, Response);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
public:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
FilteredResponse(JS::NonnullGCPtr<Response>, JS::NonnullGCPtr<HeaderList>);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
virtual ~FilteredResponse() = 0;
LibWeb: Make Fetch::Infrastructure::{Request,Response} ref-counted With the addition of the 'fetch params' struct, the single ownership model we had so far falls apart completely. Additionally, this works nicely for FilteredResponse's internal response instead of risking a dangling reference. Replacing the public constructor with a create() function also found a few instances of a Request being stack-allocated!
2022-10-04 23:45:47 +01:00
[[nodiscard]] virtual Type type() const override { return m_internal_response->type(); }
[[nodiscard]] virtual bool aborted() const override { return m_internal_response->aborted(); }
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
[[nodiscard]] virtual Vector<URL::URL> const& url_list() const override { return m_internal_response->url_list(); }
[[nodiscard]] virtual Vector<URL::URL>& url_list() override { return m_internal_response->url_list(); }
LibWeb: Make Fetch::Infrastructure::{Request,Response} ref-counted With the addition of the 'fetch params' struct, the single ownership model we had so far falls apart completely. Additionally, this works nicely for FilteredResponse's internal response instead of risking a dangling reference. Replacing the public constructor with a create() function also found a few instances of a Request being stack-allocated!
2022-10-04 23:45:47 +01:00
[[nodiscard]] virtual Status status() const override { return m_internal_response->status(); }
[[nodiscard]] virtual ReadonlyBytes status_message() const override { return m_internal_response->status_message(); }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] virtual JS::NonnullGCPtr<HeaderList> header_list() const override { return m_internal_response->header_list(); }
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
[[nodiscard]] virtual JS::GCPtr<Body> const& body() const override { return m_internal_response->body(); }
[[nodiscard]] virtual JS::GCPtr<Body>& body() override { return m_internal_response->body(); }
LibWeb: Make Fetch::Infrastructure::{Request,Response} ref-counted With the addition of the 'fetch params' struct, the single ownership model we had so far falls apart completely. Additionally, this works nicely for FilteredResponse's internal response instead of risking a dangling reference. Replacing the public constructor with a create() function also found a few instances of a Request being stack-allocated!
2022-10-04 23:45:47 +01:00
[[nodiscard]] virtual Optional<CacheState> const& cache_state() const override { return m_internal_response->cache_state(); }
[[nodiscard]] virtual Vector<ByteBuffer> const& cors_exposed_header_name_list() const override { return m_internal_response->cors_exposed_header_name_list(); }
[[nodiscard]] virtual bool range_requested() const override { return m_internal_response->range_requested(); }
[[nodiscard]] virtual bool request_includes_credentials() const override { return m_internal_response->request_includes_credentials(); }
[[nodiscard]] virtual bool timing_allow_passed() const override { return m_internal_response->timing_allow_passed(); }
[[nodiscard]] virtual BodyInfo const& body_info() const override { return m_internal_response->body_info(); }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] JS::NonnullGCPtr<Response> internal_response() const { return m_internal_response; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
protected:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
virtual void visit_edges(JS::Cell::Visitor&) override;
private:
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
// https://fetch.spec.whatwg.org/#concept-internal-response
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS::NonnullGCPtr<Response> m_internal_response;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
// https://fetch.spec.whatwg.org/#concept-filtered-response-basic
class BasicFilteredResponse final : public FilteredResponse {
LibJS+LibWeb: Fix a ton of JS_CELL-like macro issues
2024-05-19 13:48:52 -07:00
JS_CELL(BasicFilteredResponse, FilteredResponse);
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_DECLARE_ALLOCATOR(BasicFilteredResponse);
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
public:
LibWeb: Remove OOM propagation from Fetch::Infrastructure::Responses
2024-04-26 13:42:39 -04:00
[[nodiscard]] static JS::NonnullGCPtr<BasicFilteredResponse> create(JS::VM&, JS::NonnullGCPtr<Response>);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Type type() const override { return Type::Basic; }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] virtual JS::NonnullGCPtr<HeaderList> header_list() const override { return m_header_list; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
private:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
BasicFilteredResponse(JS::NonnullGCPtr<Response>, JS::NonnullGCPtr<HeaderList>);
virtual void visit_edges(JS::Cell::Visitor&) override;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS::NonnullGCPtr<HeaderList> m_header_list;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
// https://fetch.spec.whatwg.org/#concept-filtered-response-cors
class CORSFilteredResponse final : public FilteredResponse {
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS_CELL(CORSFilteredResponse, FilteredResponse);
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_DECLARE_ALLOCATOR(CORSFilteredResponse);
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
public:
LibWeb: Remove OOM propagation from Fetch::Infrastructure::Responses
2024-04-26 13:42:39 -04:00
[[nodiscard]] static JS::NonnullGCPtr<CORSFilteredResponse> create(JS::VM&, JS::NonnullGCPtr<Response>);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Type type() const override { return Type::CORS; }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] virtual JS::NonnullGCPtr<HeaderList> header_list() const override { return m_header_list; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
private:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
CORSFilteredResponse(JS::NonnullGCPtr<Response>, JS::NonnullGCPtr<HeaderList>);
virtual void visit_edges(JS::Cell::Visitor&) override;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS::NonnullGCPtr<HeaderList> m_header_list;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
// https://fetch.spec.whatwg.org/#concept-filtered-response-opaque
class OpaqueFilteredResponse final : public FilteredResponse {
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS_CELL(OpaqueFilteredResponse, FilteredResponse);
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_DECLARE_ALLOCATOR(OpaqueFilteredResponse);
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
public:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] static JS::NonnullGCPtr<OpaqueFilteredResponse> create(JS::VM&, JS::NonnullGCPtr<Response>);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Type type() const override { return Type::Opaque; }
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
[[nodiscard]] virtual Vector<URL::URL> const& url_list() const override { return m_url_list; }
[[nodiscard]] virtual Vector<URL::URL>& url_list() override { return m_url_list; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Status status() const override { return 0; }
[[nodiscard]] virtual ReadonlyBytes status_message() const override { return {}; }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] virtual JS::NonnullGCPtr<HeaderList> header_list() const override { return m_header_list; }
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
[[nodiscard]] virtual JS::GCPtr<Body> const& body() const override { return m_body; }
[[nodiscard]] virtual JS::GCPtr<Body>& body() override { return m_body; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
private:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
OpaqueFilteredResponse(JS::NonnullGCPtr<Response>, JS::NonnullGCPtr<HeaderList>);
virtual void visit_edges(JS::Cell::Visitor&) override;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
Vector<URL::URL> m_url_list;
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS::NonnullGCPtr<HeaderList> m_header_list;
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::GCPtr<Body> m_body;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
// https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect
class OpaqueRedirectFilteredResponse final : public FilteredResponse {
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS_CELL(OpaqueRedirectFilteredResponse, FilteredResponse);
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_DECLARE_ALLOCATOR(OpaqueRedirectFilteredResponse);
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
public:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] static JS::NonnullGCPtr<OpaqueRedirectFilteredResponse> create(JS::VM&, JS::NonnullGCPtr<Response>);
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Type type() const override { return Type::OpaqueRedirect; }
[[nodiscard]] virtual Status status() const override { return 0; }
[[nodiscard]] virtual ReadonlyBytes status_message() const override { return {}; }
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
[[nodiscard]] virtual JS::NonnullGCPtr<HeaderList> header_list() const override { return m_header_list; }
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
[[nodiscard]] virtual JS::GCPtr<Body> const& body() const override { return m_body; }
[[nodiscard]] virtual JS::GCPtr<Body>& body() override { return m_body; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
private:
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
OpaqueRedirectFilteredResponse(JS::NonnullGCPtr<Response>, JS::NonnullGCPtr<HeaderList>);
virtual void visit_edges(JS::Cell::Visitor&) override;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
LibWeb: Make Fetch::Infrastructure::{Request,Response,HeaderList} GC'd This is the way. On a more serious note, there's no reason to keep adding ref-counted classes to LibWeb now that the majority of classes is GC'd - it only adds the risk of discovering some cycle down the line, and forces us to use handles as we can't visit().
2022-10-30 01:52:07 +00:00
JS::NonnullGCPtr<HeaderList> m_header_list;
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::GCPtr<Body> m_body;
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
};
}
Reference in a new issue Copy permalink