mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-24 10:12:25 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Fetch/Response.h

81 lines
3 KiB
C
Raw Normal View History

LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
/*
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
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Forward.h>
#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 08:29:14 -05:00
#include <LibJS/Heap/GCPtr.h>
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
#include <LibWeb/Bindings/PlatformObject.h>
#include <LibWeb/Fetch/Body.h>
#include <LibWeb/Fetch/BodyInit.h>
#include <LibWeb/Fetch/Headers.h>
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
#include <LibWeb/Fetch/Infrastructure/HTTP/Responses.h>
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
#include <LibWeb/Forward.h>
namespace Web::Fetch {
// https://fetch.spec.whatwg.org/#responseinit
struct ResponseInit {
u16 status;
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
String status_text;
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
Optional<HeadersInit> headers;
};
// https://fetch.spec.whatwg.org/#response
class Response final
: public Bindings::PlatformObject
, public BodyMixin {
WEB_PLATFORM_OBJECT(Response, Bindings::PlatformObject);
public:
LibWeb: Make factory method of Fetch::Response fallible
2023-02-19 17:49:52 +01:00
static WebIDL::ExceptionOr<JS::NonnullGCPtr<Response>> create(JS::Realm&, JS::NonnullGCPtr<Infrastructure::Response>, Headers::Guard);
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-25 18:08:29 -06:00
static WebIDL::ExceptionOr<JS::NonnullGCPtr<Response>> construct_impl(JS::Realm&, Optional<BodyInit> const& body = {}, ResponseInit const& init = {});
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
virtual ~Response() override;
// ^BodyMixin
virtual Optional<MimeSniff::MimeType> mime_type_impl() const override;
virtual Optional<Infrastructure::Body&> body_impl() override;
virtual Optional<Infrastructure::Body const&> body_impl() const 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
[[nodiscard]] JS::NonnullGCPtr<Infrastructure::Response> response() const { return m_response; }
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
// JS API functions
BindingsGenerator+LibWeb: Pass a VM to static IDL-based functions This saves us from having to yoink the VM out of thin air.
2022-10-05 17:09:26 +01:00
[[nodiscard]] static JS::NonnullGCPtr<Response> error(JS::VM&);
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
static WebIDL::ExceptionOr<JS::NonnullGCPtr<Response>> redirect(JS::VM&, String const& url, u16 status);
static WebIDL::ExceptionOr<JS::NonnullGCPtr<Response>> json(JS::VM&, JS::Value data, ResponseInit const& init = {});
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
[[nodiscard]] Bindings::ResponseType type() 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
[[nodiscard]] WebIDL::ExceptionOr<String> url() const;
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
[[nodiscard]] bool redirected() const;
[[nodiscard]] u16 status() const;
[[nodiscard]] bool ok() 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
[[nodiscard]] WebIDL::ExceptionOr<String> status_text() const;
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
[[nodiscard]] JS::NonnullGCPtr<Headers> headers() const;
[[nodiscard]] WebIDL::ExceptionOr<JS::NonnullGCPtr<Response>> clone() const;
// Pull in json() from the BodyMixin, which gets lost due to the static json() above
using BodyMixin::json;
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
Response(JS::Realm&, JS::NonnullGCPtr<Infrastructure::Response>);
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
LibJS+Everywhere: Allow Cell::initialize overrides to throw OOM errors Note that as of this commit, there aren't any such throwers, and the call site in Heap::allocate will drop exceptions on the floor. This commit only serves to change the declaration of the overrides, make sure they return an empty value, and to propagate OOM errors frm their base initialize invocations.
2023-01-28 12:33:35 -05:00
virtual JS::ThrowCompletionOr<void> initialize(JS::Realm&) override;
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
virtual void visit_edges(Cell::Visitor&) override;
WebIDL::ExceptionOr<void> initialize_response(ResponseInit const&, Optional<Infrastructure::BodyWithType> const&);
// https://fetch.spec.whatwg.org/#concept-response-response
// A Response object has an associated response (a 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<Infrastructure::Response> m_response;
LibWeb: Implement '5.5. Response class' from the Fetch API :^)
2022-09-25 19:36:30 +01:00
// https://fetch.spec.whatwg.org/#response-headers
// A Response object also has an associated headers (null or a Headers object), initially null.
JS::GCPtr<Headers> m_headers;
};
}
Reference in a new issue Copy permalink