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/Userland/Libraries/LibWeb/Fetch/Infrastructure/HTTP/Responses.h

304 lines
14 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>
#include <AK/URL.h>
#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>
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: 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: 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; }
[[nodiscard]] virtual Vector<AK::URL> const& url_list() const { return m_url_list; }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Vector<AK::URL>& url_list() { return m_url_list; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
void set_url_list(Vector<AK::URL> url_list) { m_url_list = move(url_list); }
[[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
[[nodiscard]] virtual Optional<Body> const& body() const { return m_body; }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Optional<Body>& body() { return m_body; }
LibWeb: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
void set_body(Optional<Body> body) { m_body = move(body); }
[[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;
[[nodiscard]] Optional<AK::URL const&> url() const;
LibWeb/Fetch: Port infrastructure to new String
2023-03-02 23:26:35 +00:00
[[nodiscard]] ErrorOr<Optional<AK::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: Propagate Realm instead of VM more through Fetch This makes Fetch rely less on using main_thread_vm().current_realm(), which relies on the dummy execution context if no JavaScript is currently running.
2023-02-28 17:45:49 +00:00
[[nodiscard]] WebIDL::ExceptionOr<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 is CORS-cross-origin AO
2023-05-10 16:27:55 -04:00
[[nodiscard]] bool is_cors_cross_origin() 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.
Vector<AK::URL> m_url_list;
// 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.
Optional<Body> m_body;
// 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
// 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
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(); }
[[nodiscard]] virtual Vector<AK::URL> const& url_list() const override { return m_internal_response->url_list(); }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Vector<AK::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::{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<Body> const& body() const override { return m_internal_response->body(); }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Optional<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 {
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: 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 ErrorOr<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: 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 ErrorOr<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: 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; }
[[nodiscard]] virtual Vector<AK::URL> const& url_list() const override { return m_url_list; }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Vector<AK::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: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Optional<Body> const& body() const override { return m_body; }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Optional<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
Vector<AK::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: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
Optional<Body> m_body;
};
// 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: 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: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
[[nodiscard]] virtual Optional<Body> const& body() const override { return m_body; }
LibWeb: Also make non-const Response getters virtual We wouldn't want a filtered response to bypass the overridden methods based on constness.
2022-10-24 18:49:06 +01:00
[[nodiscard]] virtual Optional<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: Add definitions from '2.2.6. Responses' in the Fetch spec
2022-07-16 17:55:29 +01:00
Optional<Body> m_body;
};
}
Reference in a new issue Copy permalink