2020-01-18 09:38:21 +01:00
|
|
|
/*
|
2024-10-04 13:19:50 +02:00
|
|
|
* Copyright (c) 2018-2020, Andreas Kling <andreas@ladybird.org>
|
2020-01-18 09:38:21 +01:00
|
|
|
*
|
2021-04-22 01:24:48 -07:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-01-18 09:38:21 +01:00
|
|
|
*/
|
|
|
|
|
2019-11-24 13:20:44 +01:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <AK/Badge.h>
|
2023-12-16 17:49:34 +03:30
|
|
|
#include <AK/ByteString.h>
|
2019-11-24 13:20:44 +01:00
|
|
|
#include <AK/Function.h>
|
2023-01-25 20:19:05 +01:00
|
|
|
#include <AK/MemoryStream.h>
|
2019-11-24 13:20:44 +01:00
|
|
|
#include <AK/RefCounted.h>
|
|
|
|
#include <AK/WeakPtr.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 17:14:12 +03:30
|
|
|
#include <LibCore/Notifier.h>
|
2024-06-09 11:28:37 +02:00
|
|
|
#include <LibHTTP/HeaderMap.h>
|
2025-03-30 13:09:50 -04:00
|
|
|
#include <LibRequests/NetworkError.h>
|
2025-02-26 13:28:21 +00:00
|
|
|
#include <LibRequests/RequestTimingInfo.h>
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2024-08-06 21:51:20 -06:00
|
|
|
namespace Requests {
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2021-04-23 22:45:52 +02:00
|
|
|
class RequestClient;
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2021-04-23 22:45:52 +02:00
|
|
|
class Request : public RefCounted<Request> {
|
2019-11-24 13:20:44 +01:00
|
|
|
public:
|
2020-08-02 05:27:42 +04:30
|
|
|
struct CertificateAndKey {
|
2023-12-16 17:49:34 +03:30
|
|
|
ByteString certificate;
|
|
|
|
ByteString key;
|
2020-08-02 05:27:42 +04:30
|
|
|
};
|
|
|
|
|
2021-04-23 22:45:52 +02:00
|
|
|
static NonnullRefPtr<Request> create_from_id(Badge<RequestClient>, RequestClient& client, i32 request_id)
|
2019-11-24 13:20:44 +01:00
|
|
|
{
|
2021-04-23 22:45:52 +02:00
|
|
|
return adopt_ref(*new Request(client, request_id));
|
2019-11-24 13:20:44 +01:00
|
|
|
}
|
|
|
|
|
2021-04-23 22:45:52 +02:00
|
|
|
int 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 17:14:12 +03:30
|
|
|
int fd() const { return m_fd; }
|
2019-11-24 13:20:44 +01:00
|
|
|
bool stop();
|
|
|
|
|
2025-02-26 13:28:21 +00:00
|
|
|
using BufferedRequestFinished = Function<void(u64 total_size, RequestTimingInfo const& timing_info, Optional<NetworkError> const& network_error, HTTP::HeaderMap const& response_headers, Optional<u32> response_code, Optional<String> reason_phrase, ReadonlyBytes 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 17:14:12 +03:30
|
|
|
|
2024-05-24 11:37:02 -04: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);
|
|
|
|
|
2024-10-23 16:46:26 -05:00
|
|
|
using HeadersReceived = Function<void(HTTP::HeaderMap const& response_headers, Optional<u32> response_code, Optional<String> const& reason_phrase)>;
|
2024-05-24 11:37:02 -04:00
|
|
|
using DataReceived = Function<void(ReadonlyBytes data)>;
|
2025-02-26 13:28:21 +00:00
|
|
|
using RequestFinished = Function<void(u64 total_size, RequestTimingInfo const& timing_info, Optional<NetworkError> network_error)>;
|
2024-05-24 11:37:02 -04: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`.
|
|
|
|
void set_unbuffered_request_callbacks(HeadersReceived, DataReceived, 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 17:14:12 +03:30
|
|
|
|
2020-08-02 05:27:42 +04:30
|
|
|
Function<CertificateAndKey()> on_certificate_requested;
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2025-02-26 13:28:21 +00:00
|
|
|
void did_finish(Badge<RequestClient>, u64 total_size, RequestTimingInfo const& timing_info, Optional<NetworkError> const& network_error);
|
2024-10-23 16:46:26 -05:00
|
|
|
void did_receive_headers(Badge<RequestClient>, HTTP::HeaderMap const& response_headers, Optional<u32> response_code, Optional<String> const& reason_phrase);
|
2021-04-23 22:45:52 +02:00
|
|
|
void did_request_certificates(Badge<RequestClient>);
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2021-04-23 22:45:52 +02:00
|
|
|
RefPtr<Core::Notifier>& write_notifier(Badge<RequestClient>) { return m_write_notifier; }
|
2024-02-24 14:36:57 +01:00
|
|
|
void set_request_fd(Badge<RequestClient>, int fd);
|
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 17:14:12 +03:30
|
|
|
|
2019-11-24 13:20:44 +01:00
|
|
|
private:
|
2021-04-23 22:45:52 +02:00
|
|
|
explicit Request(RequestClient&, i32 request_id);
|
2022-02-02 19:21:55 +03:30
|
|
|
|
2024-05-24 11:37:02 -04:00
|
|
|
void set_up_internal_stream_data(DataReceived on_data_available);
|
|
|
|
|
2021-04-23 22:45:52 +02:00
|
|
|
WeakPtr<RequestClient> m_client;
|
|
|
|
int m_request_id { -1 };
|
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 17:14:12 +03:30
|
|
|
RefPtr<Core::Notifier> m_write_notifier;
|
|
|
|
int m_fd { -1 };
|
2024-05-24 11:37:02 -04: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 17:14:12 +03:30
|
|
|
|
|
|
|
struct InternalBufferedData {
|
2023-01-25 20:19:05 +01:00
|
|
|
AllocatingMemoryStream payload_stream;
|
2024-06-09 11:28:37 +02:00
|
|
|
HTTP::HeaderMap 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 17:14:12 +03:30
|
|
|
Optional<u32> response_code;
|
2024-10-23 16:46:26 -05:00
|
|
|
Optional<String> reason_phrase;
|
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 17:14:12 +03:30
|
|
|
};
|
|
|
|
|
|
|
|
struct InternalStreamData {
|
2024-02-24 14:36:57 +01: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 17:14:12 +03:30
|
|
|
|
2024-02-24 14:36:57 +01:00
|
|
|
OwnPtr<Stream> 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 17:14:12 +03:30
|
|
|
RefPtr<Core::Notifier> read_notifier;
|
|
|
|
u32 total_size { 0 };
|
2024-10-09 17:01:34 -05:00
|
|
|
Optional<NetworkError> network_error;
|
2021-04-23 22:45:52 +02:00
|
|
|
bool request_done { false };
|
2025-02-26 13:28:21 +00:00
|
|
|
RequestTimingInfo timing_info;
|
2022-02-02 19:21:55 +03:30
|
|
|
Function<void()> on_finish {};
|
|
|
|
bool user_finish_called { false };
|
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 17:14:12 +03:30
|
|
|
};
|
|
|
|
|
|
|
|
OwnPtr<InternalBufferedData> m_internal_buffered_data;
|
|
|
|
OwnPtr<InternalStreamData> m_internal_stream_data;
|
2019-11-24 13:20:44 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|