2020-01-18 05:38:21 -03:00
|
|
|
/*
|
2024-10-04 08:19:50 -03:00
|
|
|
* Copyright (c) 2018-2020, Andreas Kling <andreas@ladybird.org>
|
2020-01-18 05:38:21 -03:00
|
|
|
*
|
2021-04-22 05:24:48 -03:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-01-18 05:38:21 -03:00
|
|
|
*/
|
|
|
|
|
|
2019-11-24 09:20:44 -03:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <AK/Badge.h>
|
2023-12-16 11:19:34 -03:00
|
|
|
#include <AK/ByteString.h>
|
2019-11-24 09:20:44 -03:00
|
|
|
#include <AK/Function.h>
|
2023-01-25 16:19:05 -03:00
|
|
|
#include <AK/MemoryStream.h>
|
2026-02-21 08:13:28 -03:00
|
|
|
#include <AK/OwnPtr.h>
|
2019-11-24 09:20:44 -03:00
|
|
|
#include <AK/RefCounted.h>
|
|
|
|
|
#include <AK/WeakPtr.h>
|
2026-05-15 09:37:07 -03:00
|
|
|
#include <LibCore/ImmutableBytes.h>
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
#include <LibCore/Notifier.h>
|
2025-11-26 16:13:23 -03:00
|
|
|
#include <LibHTTP/HeaderList.h>
|
2025-03-30 14:09:50 -03:00
|
|
|
#include <LibRequests/NetworkError.h>
|
2025-02-26 10:28:21 -03:00
|
|
|
#include <LibRequests/RequestTimingInfo.h>
|
2019-11-24 09:20:44 -03:00
|
|
|
|
2024-08-07 00:51:20 -03:00
|
|
|
namespace Requests {
|
2019-11-24 09:20:44 -03:00
|
|
|
|
2021-04-23 17:45:52 -03:00
|
|
|
class RequestClient;
|
2019-11-24 09:20:44 -03:00
|
|
|
|
2026-05-15 09:49:12 -03:00
|
|
|
class ResponseData {
|
|
|
|
|
public:
|
|
|
|
|
static ResponseData from_bytes(ReadonlyBytes bytes) { return ResponseData { bytes }; }
|
|
|
|
|
static ResponseData from_immutable_bytes(Core::ImmutableBytes bytes) { return ResponseData { move(bytes) }; }
|
|
|
|
|
|
|
|
|
|
[[nodiscard]] ReadonlyBytes bytes() const
|
|
|
|
|
{
|
|
|
|
|
if (m_immutable_bytes.has_value())
|
|
|
|
|
return m_immutable_bytes->bytes();
|
|
|
|
|
return m_bytes;
|
|
|
|
|
}
|
|
|
|
|
[[nodiscard]] Optional<Core::ImmutableBytes> const& immutable_bytes() const { return m_immutable_bytes; }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
explicit ResponseData(ReadonlyBytes bytes)
|
|
|
|
|
: m_bytes(bytes)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
explicit ResponseData(Core::ImmutableBytes bytes)
|
|
|
|
|
: m_immutable_bytes(move(bytes))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ReadonlyBytes m_bytes;
|
|
|
|
|
Optional<Core::ImmutableBytes> m_immutable_bytes;
|
|
|
|
|
};
|
|
|
|
|
|
2025-08-24 19:12:33 -03:00
|
|
|
class ReadStream {
|
|
|
|
|
public:
|
|
|
|
|
static ErrorOr<NonnullOwnPtr<ReadStream>> create(int reader_fd);
|
|
|
|
|
|
|
|
|
|
NonnullRefPtr<Core::Notifier> const& notifier() const { return m_notifier; }
|
|
|
|
|
|
|
|
|
|
bool is_eof() const { return m_stream->is_eof(); }
|
|
|
|
|
|
|
|
|
|
ErrorOr<Bytes> read_some(Bytes bytes) { return m_stream->read_some(bytes); }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
ReadStream(NonnullOwnPtr<Stream> stream, NonnullRefPtr<Core::Notifier> notifier)
|
|
|
|
|
: m_stream(move(stream))
|
|
|
|
|
, m_notifier(move(notifier))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NonnullOwnPtr<Stream> m_stream;
|
|
|
|
|
NonnullRefPtr<Core::Notifier> m_notifier;
|
|
|
|
|
};
|
|
|
|
|
|
2026-02-17 21:05:58 -03:00
|
|
|
class Request : public RefCounted<Request>
|
|
|
|
|
, public Weakable<Request> {
|
2019-11-24 09:20:44 -03:00
|
|
|
public:
|
2020-08-01 21:57:42 -03:00
|
|
|
struct CertificateAndKey {
|
2023-12-16 11:19:34 -03:00
|
|
|
ByteString certificate;
|
|
|
|
|
ByteString key;
|
2020-08-01 21:57:42 -03:00
|
|
|
};
|
|
|
|
|
|
2025-12-12 11:56:53 -03:00
|
|
|
static NonnullRefPtr<Request> create_from_id(Badge<RequestClient>, RequestClient& client, u64 request_id)
|
2019-11-24 09:20:44 -03:00
|
|
|
{
|
2021-04-23 17:45:52 -03:00
|
|
|
return adopt_ref(*new Request(client, request_id));
|
2019-11-24 09:20:44 -03:00
|
|
|
}
|
|
|
|
|
|
2025-12-12 11:56:53 -03:00
|
|
|
u64 id() const { return m_request_id; }
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
int fd() const { return m_fd; }
|
2019-11-24 09:20:44 -03:00
|
|
|
bool stop();
|
|
|
|
|
|
2026-05-15 11:34:54 -03:00
|
|
|
using BufferedRequestFinished = Function<void(u64 total_size, RequestTimingInfo const& timing_info, Optional<NetworkError> const& network_error, NonnullRefPtr<HTTP::HeaderList> response_headers, Optional<u32> response_code, Optional<String> reason_phrase, Optional<Core::ImmutableBytes> javascript_bytecode, Optional<u64> javascript_bytecode_cache_vary_key, Core::ImmutableBytes payload)>;
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
|
2024-05-24 12:37:02 -03:00
|
|
|
// Configure the request such that the entirety of the response data is buffered. The callback receives that data and
|
|
|
|
|
// the response headers all at once. Using this method is mutually exclusive with `set_unbuffered_data_received_callback`.
|
|
|
|
|
void set_buffered_request_finished_callback(BufferedRequestFinished);
|
|
|
|
|
|
2026-05-15 11:34:54 -03:00
|
|
|
using HeadersReceived = Function<void(NonnullRefPtr<HTTP::HeaderList> response_headers, Optional<u32> response_code, Optional<String> const& reason_phrase, Optional<Core::ImmutableBytes> javascript_bytecode, Optional<u64> javascript_bytecode_cache_vary_key)>;
|
2026-05-15 09:49:12 -03:00
|
|
|
using DataReceived = Function<void(ResponseData data)>;
|
2026-05-15 09:58:56 -03:00
|
|
|
using CachedBodyAvailable = Function<void(Core::ImmutableBytes data)>;
|
2025-02-26 10:28:21 -03:00
|
|
|
using RequestFinished = Function<void(u64 total_size, RequestTimingInfo const& timing_info, Optional<NetworkError> network_error)>;
|
2024-05-24 12:37:02 -03:00
|
|
|
|
|
|
|
|
// Configure the request such that the response data is provided unbuffered as it is received. Using this method is
|
|
|
|
|
// mutually exclusive with `set_buffered_request_finished_callback`.
|
2026-05-15 09:58:56 -03:00
|
|
|
void set_unbuffered_request_callbacks(HeadersReceived, DataReceived, CachedBodyAvailable, RequestFinished);
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
|
2020-08-01 21:57:42 -03:00
|
|
|
Function<CertificateAndKey()> on_certificate_requested;
|
2019-11-24 09:20:44 -03:00
|
|
|
|
2025-02-26 10:28:21 -03:00
|
|
|
void did_finish(Badge<RequestClient>, u64 total_size, RequestTimingInfo const& timing_info, Optional<NetworkError> const& network_error);
|
2026-05-15 11:34:54 -03:00
|
|
|
void did_receive_headers(Badge<RequestClient>, NonnullRefPtr<HTTP::HeaderList> response_headers, Optional<u32> response_code, Optional<String> const& reason_phrase, Optional<Core::ImmutableBytes> javascript_bytecode, Optional<u64> javascript_bytecode_cache_vary_key);
|
2021-04-23 17:45:52 -03:00
|
|
|
void did_request_certificates(Badge<RequestClient>);
|
2019-11-24 09:20:44 -03:00
|
|
|
|
2021-04-23 17:45:52 -03:00
|
|
|
RefPtr<Core::Notifier>& write_notifier(Badge<RequestClient>) { return m_write_notifier; }
|
2024-02-24 10:36:57 -03:00
|
|
|
void set_request_fd(Badge<RequestClient>, int fd);
|
2026-05-15 09:37:07 -03:00
|
|
|
void set_request_body_file(Badge<RequestClient>, int fd, u64 offset, u64 size);
|
2026-05-15 09:58:56 -03:00
|
|
|
void set_request_cached_body_file(Badge<RequestClient>, int fd, u64 offset, u64 size);
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
|
2019-11-24 09:20:44 -03:00
|
|
|
private:
|
2025-12-12 11:56:53 -03:00
|
|
|
Request(RequestClient&, u64 request_id);
|
2022-02-02 12:51:55 -03:00
|
|
|
|
2024-05-24 12:37:02 -03:00
|
|
|
void set_up_internal_stream_data(DataReceived on_data_available);
|
|
|
|
|
|
2021-04-23 17:45:52 -03:00
|
|
|
WeakPtr<RequestClient> m_client;
|
2025-12-12 11:56:53 -03:00
|
|
|
u64 m_request_id { 0 };
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
RefPtr<Core::Notifier> m_write_notifier;
|
|
|
|
|
int m_fd { -1 };
|
2024-05-24 12:37:02 -03:00
|
|
|
|
|
|
|
|
enum class Mode {
|
|
|
|
|
Buffered,
|
|
|
|
|
Unbuffered,
|
|
|
|
|
Unknown,
|
|
|
|
|
};
|
|
|
|
|
Mode m_mode { Mode::Unknown };
|
|
|
|
|
|
|
|
|
|
HeadersReceived on_headers_received;
|
|
|
|
|
RequestFinished on_finish;
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
|
|
|
|
|
struct InternalBufferedData {
|
2025-11-26 16:13:23 -03:00
|
|
|
InternalBufferedData();
|
|
|
|
|
|
2023-01-25 16:19:05 -03:00
|
|
|
AllocatingMemoryStream payload_stream;
|
2025-11-26 16:13:23 -03:00
|
|
|
NonnullRefPtr<HTTP::HeaderList> response_headers;
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
Optional<u32> response_code;
|
2024-10-23 18:46:26 -03:00
|
|
|
Optional<String> reason_phrase;
|
2026-05-15 11:34:54 -03:00
|
|
|
Optional<Core::ImmutableBytes> javascript_bytecode;
|
2026-05-03 15:04:35 -03:00
|
|
|
Optional<u64> javascript_bytecode_cache_vary_key;
|
2026-05-15 09:37:07 -03:00
|
|
|
Optional<Core::ImmutableBytes> payload;
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct InternalStreamData {
|
2024-02-24 10:36:57 -03:00
|
|
|
InternalStreamData() { }
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
|
2025-08-24 19:12:33 -03:00
|
|
|
OwnPtr<ReadStream> read_stream;
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
RefPtr<Core::Notifier> read_notifier;
|
2026-05-15 09:37:07 -03:00
|
|
|
u64 total_size { 0 };
|
2024-10-09 19:01:34 -03:00
|
|
|
Optional<NetworkError> network_error;
|
2021-04-23 17:45:52 -03:00
|
|
|
bool request_done { false };
|
2025-02-26 10:28:21 -03:00
|
|
|
RequestTimingInfo timing_info;
|
2026-05-15 09:37:07 -03:00
|
|
|
DataReceived on_data_available;
|
2026-05-15 09:58:56 -03:00
|
|
|
CachedBodyAvailable on_cached_body_available;
|
2022-02-02 12:51:55 -03:00
|
|
|
Function<void()> on_finish {};
|
|
|
|
|
bool user_finish_called { false };
|
2026-05-15 09:37:07 -03:00
|
|
|
Optional<Core::ImmutableBytes> file_backed_payload;
|
2026-05-15 09:58:56 -03:00
|
|
|
Optional<Core::ImmutableBytes> cached_payload;
|
ProtocolServer: Stream the downloaded data if possible
This patchset makes ProtocolServer stream the downloads to its client
(LibProtocol), and as such changes the download API; a possible
download lifecycle could be as such:
notation = client->server:'>', server->client:'<', pipe activity:'*'
```
> StartDownload(GET, url, headers, {})
< Response(0, fd 8)
* {data, 1024b}
< HeadersBecameAvailable(0, response_headers, 200)
< DownloadProgress(0, 4K, 1024)
* {data, 1024b}
* {data, 1024b}
< DownloadProgress(0, 4K, 2048)
* {data, 1024b}
< DownloadProgress(0, 4K, 1024)
< DownloadFinished(0, true, 4K)
```
Since managing the received file descriptor is a pain, LibProtocol
implements `Download::stream_into(OutputStream)`, which can be used to
stream the download into any given output stream (be it a file, or
memory, or writing stuff with a delay, etc.).
Also, as some of the users of this API require all the downloaded data
upfront, LibProtocol also implements `set_should_buffer_all_input()`,
which causes the download instance to buffer all the data until the
download is complete, and to call the `on_buffered_download_finish`
hook.
2020-12-26 10:44:12 -03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
OwnPtr<InternalBufferedData> m_internal_buffered_data;
|
|
|
|
|
OwnPtr<InternalStreamData> m_internal_stream_data;
|
2026-05-15 11:24:03 -03:00
|
|
|
Optional<NetworkError> m_body_delivery_error;
|
2019-11-24 09:20:44 -03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
}
|