beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 23:50:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibWeb/Fetch/Headers.h

82 lines
2.8 KiB
C
Raw Normal View History

LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
/*
LibWeb: Implement Headers.getSetCookie() This is a normative change in the Fetch spec. See: https://github.com/whatwg/fetch/commit/e4d3480 This also implements the changes to the 'sort and combine' algorithm, which now treats "set-cookie" headers differently, and is exposed to JS via the Headers' iterator. Passes all 21 WPT tests :^) http://wpt.live/fetch/api/headers/header-setcookie.any.html
2023-02-10 22:02:18 +00:00
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/HashMap.h>
LibWeb/Fetch: Port JS interfaces to new String Since BodyInit and Headers are tightly coupled to both Request and Response, I chose to do all of them at once instead of introducing a bunch of temporary conversion glue code.
2023-03-02 22:26:12 +00:00
#include <AK/String.h>
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
#include <AK/Variant.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>
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 13:29:14 +00:00
#include <LibJS/Heap/GCPtr.h>
LibWeb: Make Headers and HeadersIterator GC-allocated
2022-09-04 10:48:49 +00:00
#include <LibWeb/Bindings/PlatformObject.h>
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
#include <LibWeb/Fetch/Infrastructure/HTTP/Headers.h>
LibWeb: Move ExceptionOr from DOM/ to WebIDL/ This is a concept fully defined in the Web IDL spec and doesn't belong in the DOM directory/namespace - not even DOMException, despite the name :^)
2022-09-25 16:03:42 +00:00
#include <LibWeb/WebIDL/ExceptionOr.h>
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
namespace Web::Fetch {
LibWeb/Fetch: Port JS interfaces to new String Since BodyInit and Headers are tightly coupled to both Request and Response, I chose to do all of them at once instead of introducing a bunch of temporary conversion glue code.
2023-03-02 22:26:12 +00:00
using HeadersInit = Variant<Vector<Vector<String>>, OrderedHashMap<String, String>>;
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
// https://fetch.spec.whatwg.org/#headers-class
LibWeb: Make Headers and HeadersIterator GC-allocated
2022-09-04 10:48:49 +00:00
class Headers final : public Bindings::PlatformObject {
WEB_PLATFORM_OBJECT(Headers, Bindings::PlatformObject);
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 18:47:52 +00:00
JS_DECLARE_ALLOCATOR(Headers);
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
LibWeb: Make Headers and HeadersIterator GC-allocated
2022-09-04 10:48:49 +00:00
public:
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
enum class Guard {
Immutable,
Request,
RequestNoCORS,
Response,
None,
};
LibWeb: Remove unecessary dependence on Window from Fetch, XHR, FileAPI These classes only needed Window to get at its realm. Pass a realm directly to construct Fetch, XMLHttpRequest and FileAPI classes.
2022-09-26 00:08:29 +00:00
static WebIDL::ExceptionOr<JS::NonnullGCPtr<Headers>> construct_impl(JS::Realm& realm, Optional<HeadersInit> const& init);
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
LibWeb: Make Headers and HeadersIterator GC-allocated
2022-09-04 10:48:49 +00:00
virtual ~Headers() override;
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00: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]] JS::NonnullGCPtr<Infrastructure::HeaderList> header_list() const { return m_header_list; }
void set_header_list(JS::NonnullGCPtr<Infrastructure::HeaderList> header_list) { m_header_list = header_list; }
LibWeb: Add getters and setters for Fetch::Header's members
2022-09-25 13:02:47 +00:00
[[nodiscard]] Guard guard() const { return m_guard; }
void set_guard(Guard guard) { m_guard = guard; }
LibWeb: Implement '5.4. Request class' from the Fetch API :^)
2022-09-25 18:33:13 +00:00
WebIDL::ExceptionOr<void> fill(HeadersInit const&);
LibWeb/Fetch: Port JS interfaces to new String Since BodyInit and Headers are tightly coupled to both Request and Response, I chose to do all of them at once instead of introducing a bunch of temporary conversion glue code.
2023-03-02 22:26:12 +00:00
WebIDL::ExceptionOr<void> append(Infrastructure::Header);
LibWeb: Implement '5.4. Request class' from the Fetch API :^)
2022-09-25 18:33:13 +00:00
LibWeb: Add getters and setters for Fetch::Header's members
2022-09-25 13:02:47 +00:00
// JS API functions
LibWeb/Fetch: Port JS interfaces to new String Since BodyInit and Headers are tightly coupled to both Request and Response, I chose to do all of them at once instead of introducing a bunch of temporary conversion glue code.
2023-03-02 22:26:12 +00:00
WebIDL::ExceptionOr<void> append(String const& name, String const& value);
WebIDL::ExceptionOr<void> delete_(String const& name);
WebIDL::ExceptionOr<Optional<String>> get(String const& name);
LibWeb: Remove OOM propagation from Fetch::Headers
2024-04-27 14:28:36 +00:00
[[nodiscard]] Vector<String> get_set_cookie();
LibWeb/Fetch: Port JS interfaces to new String Since BodyInit and Headers are tightly coupled to both Request and Response, I chose to do all of them at once instead of introducing a bunch of temporary conversion glue code.
2023-03-02 22:26:12 +00:00
WebIDL::ExceptionOr<bool> has(String const& name);
WebIDL::ExceptionOr<void> set(String const& name, String const& value);
using ForEachCallback = Function<JS::ThrowCompletionOr<void>(String const&, String const&)>;
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
JS::ThrowCompletionOr<void> for_each(ForEachCallback);
private:
friend class HeadersIterator;
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
Headers(JS::Realm&, JS::NonnullGCPtr<Infrastructure::HeaderList>);
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
virtual void initialize(JS::Realm&) override;
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;
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
LibWeb/Fetch: Share validation logic in the Headers class This is an editorial change in the Fetch spec. See: https://github.com/whatwg/fetch/commit/f435978
2022-12-07 19:14:45 +00:00
WebIDL::ExceptionOr<bool> validate(Infrastructure::Header const&) const;
LibWeb/Fetch: Refactor forbidden request-headers This is a change in the Fetch spec. See: - https://github.com/whatwg/fetch/commit/92e6c91 - https://github.com/whatwg/xhr/commit/494431a
2022-12-07 18:16:32 +00:00
void remove_privileged_no_cors_request_headers();
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
// https://fetch.spec.whatwg.org/#concept-headers-header-list
// A Headers object has an associated header list (a header list), which is initially 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<Infrastructure::HeaderList> m_header_list;
LibWeb: Implement '5.1. Headers class' from the Fetch API :^)
2022-07-18 23:19:24 +00:00
// https://fetch.spec.whatwg.org/#concept-headers-guard
// A Headers object also has an associated guard, which is a headers guard. A headers guard is "immutable", "request", "request-no-cors", "response" or "none".
Guard m_guard { Guard::None };
};
}
Reference in a new issue Copy permalink