2020-01-18 09:38:21 +01:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
|
|
|
|
|
*
|
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>
|
|
|
|
|
#include <AK/ByteBuffer.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>
|
2020-05-03 22:20:49 +02:00
|
|
|
#include <LibIPC/Forward.h>
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2020-02-05 18:21:30 +01:00
|
|
|
namespace Protocol {
|
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();
|
|
|
|
|
|
2024-05-24 11:37:02 -04:00
|
|
|
using BufferedRequestFinished = Function<void(bool success, u64 total_size, HashMap<ByteString, ByteString, CaseInsensitiveStringTraits> const& response_headers, Optional<u32> response_code, 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);
|
|
|
|
|
|
|
|
|
|
using HeadersReceived = Function<void(HashMap<ByteString, ByteString, CaseInsensitiveStringTraits> const& response_headers, Optional<u32> response_code)>;
|
|
|
|
|
using DataReceived = Function<void(ReadonlyBytes data)>;
|
|
|
|
|
using RequestFinished = Function<void(bool success, u64 total_size)>;
|
|
|
|
|
|
|
|
|
|
// 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
|
|
|
|
2023-06-11 00:56:35 +01:00
|
|
|
Function<void(Optional<u64> total_size, u64 downloaded_size)> on_progress;
|
2020-08-02 05:27:42 +04:30
|
|
|
Function<CertificateAndKey()> on_certificate_requested;
|
2019-11-24 13:20:44 +01:00
|
|
|
|
2023-06-11 00:56:35 +01:00
|
|
|
void did_finish(Badge<RequestClient>, bool success, u64 total_size);
|
|
|
|
|
void did_progress(Badge<RequestClient>, Optional<u64> total_size, u64 downloaded_size);
|
2023-12-16 17:49:34 +03:30
|
|
|
void did_receive_headers(Badge<RequestClient>, HashMap<ByteString, ByteString, CaseInsensitiveStringTraits> const& response_headers, Optional<u32> response_code);
|
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;
|
2023-12-16 17:49:34 +03:30
|
|
|
HashMap<ByteString, ByteString, CaseInsensitiveStringTraits> 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;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
bool success;
|
|
|
|
|
u32 total_size { 0 };
|
2021-04-23 22:45:52 +02:00
|
|
|
bool request_done { false };
|
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
|
|
|
};
|
|
|
|
|
|
|
|
|
|
}
|