2020-01-18 08:38:21 +00:00
|
|
|
/*
|
2024-10-04 11:19:50 +00:00
|
|
|
* Copyright (c) 2018-2020, Andreas Kling <andreas@ladybird.org>
|
2020-01-18 08:38:21 +00:00
|
|
|
*
|
2021-04-22 08:24:48 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-01-18 08:38:21 +00:00
|
|
|
*/
|
|
|
|
|
2019-11-23 20:45:33 +00:00
|
|
|
#pragma once
|
|
|
|
|
2020-05-03 20:20:49 +00:00
|
|
|
#include <AK/HashMap.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 13:44:12 +00:00
|
|
|
#include <AK/NonnullOwnPtr.h>
|
2020-05-03 04:31:06 +00:00
|
|
|
#include <AK/Optional.h>
|
2019-11-23 20:45:33 +00:00
|
|
|
#include <AK/RefCounted.h>
|
2024-03-18 03:22:27 +00:00
|
|
|
#include <LibURL/URL.h>
|
2021-04-23 20:45:52 +00:00
|
|
|
#include <RequestServer/Forward.h>
|
2019-11-23 20:45:33 +00:00
|
|
|
|
2021-04-23 20:45:52 +00:00
|
|
|
namespace RequestServer {
|
2019-11-23 20:45:33 +00:00
|
|
|
|
2021-04-23 20:45:52 +00:00
|
|
|
class Request {
|
2019-11-23 20:45:33 +00:00
|
|
|
public:
|
2022-03-24 02:58:03 +00:00
|
|
|
virtual ~Request() = default;
|
2019-11-23 20:45:33 +00:00
|
|
|
|
|
|
|
i32 id() const { return m_id; }
|
2024-03-18 03:22:27 +00:00
|
|
|
virtual URL::URL url() const = 0;
|
2019-11-23 20:45:33 +00:00
|
|
|
|
2020-06-13 20:19:34 +00:00
|
|
|
Optional<u32> status_code() const { return m_status_code; }
|
2023-06-10 23:56:35 +00:00
|
|
|
Optional<u64> total_size() const { return m_total_size; }
|
2019-11-23 20:45:33 +00:00
|
|
|
size_t downloaded_size() const { return m_downloaded_size; }
|
2024-06-09 09:28:37 +00:00
|
|
|
HTTP::HeaderMap const& response_headers() const { return m_response_headers; }
|
2019-11-23 20:45:33 +00:00
|
|
|
|
|
|
|
void stop();
|
2023-12-16 14:19:34 +00:00
|
|
|
virtual void set_certificate(ByteString, ByteString);
|
2019-11-23 20:45:33 +00:00
|
|
|
|
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 13:44:12 +00:00
|
|
|
// FIXME: Want Badge<Protocol>, but can't make one from HttpProtocol, etc.
|
2021-04-23 20:45:52 +00:00
|
|
|
void set_request_fd(int fd) { m_request_fd = fd; }
|
|
|
|
int request_fd() const { return m_request_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 13:44:12 +00:00
|
|
|
|
2024-07-27 22:22:58 +00:00
|
|
|
virtual void cancel() = 0;
|
|
|
|
|
2019-11-23 20:45:33 +00:00
|
|
|
void did_finish(bool success);
|
2023-06-10 23:56:35 +00:00
|
|
|
void did_progress(Optional<u64> total_size, u64 downloaded_size);
|
2020-06-13 20:19:34 +00:00
|
|
|
void set_status_code(u32 status_code) { m_status_code = status_code; }
|
2020-08-02 00:57:42 +00:00
|
|
|
void did_request_certificates();
|
2024-06-09 09:28:37 +00:00
|
|
|
void set_response_headers(HTTP::HeaderMap);
|
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 13:44:12 +00:00
|
|
|
void set_downloaded_size(size_t size) { m_downloaded_size = size; }
|
2023-02-09 02:02:46 +00:00
|
|
|
Core::File const& output_stream() const { return *m_output_stream; }
|
2019-11-23 20:45:33 +00:00
|
|
|
|
2021-01-14 19:06:54 +00:00
|
|
|
protected:
|
2024-02-24 13:36:57 +00:00
|
|
|
explicit Request(ConnectionFromClient&, NonnullOwnPtr<Core::File>&&, i32 request_id);
|
2021-01-14 19:06:54 +00:00
|
|
|
|
2019-11-23 20:45:33 +00:00
|
|
|
private:
|
2022-02-25 10:18:30 +00:00
|
|
|
ConnectionFromClient& m_client;
|
2020-05-15 19:36:40 +00:00
|
|
|
i32 m_id { 0 };
|
2021-04-23 20:45:52 +00:00
|
|
|
int m_request_fd { -1 }; // Passed to client.
|
2020-06-13 20:19:34 +00:00
|
|
|
Optional<u32> m_status_code;
|
2023-06-10 23:56:35 +00:00
|
|
|
Optional<u64> m_total_size {};
|
2019-11-23 20:45:33 +00:00
|
|
|
size_t m_downloaded_size { 0 };
|
2023-02-09 02:02:46 +00:00
|
|
|
NonnullOwnPtr<Core::File> m_output_stream;
|
2024-06-09 09:28:37 +00:00
|
|
|
HTTP::HeaderMap m_response_headers;
|
2019-11-23 20:45:33 +00:00
|
|
|
};
|
2020-05-17 14:33:09 +00:00
|
|
|
|
|
|
|
}
|