2020-05-05 08:17:40 +03:00
|
|
|
/*
|
2022-03-03 21:35:10 +03:00
|
|
|
* Copyright (c) 2020-2022, the SerenityOS developers.
|
2020-05-05 08:17:40 +03:00
|
|
|
*
|
2021-04-22 11:24:48 +03:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-05-05 08:17:40 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <AK/HashMap.h>
|
2020-05-12 01:25:10 +03:00
|
|
|
#include <AK/Optional.h>
|
2020-05-05 08:17:40 +03:00
|
|
|
#include <LibCore/NetworkJob.h>
|
2023-02-09 01:05:44 +03:00
|
|
|
#include <LibCore/Socket.h>
|
2020-05-05 08:17:40 +03:00
|
|
|
#include <LibHTTP/HttpRequest.h>
|
|
|
|
#include <LibHTTP/HttpResponse.h>
|
|
|
|
|
|
|
|
namespace HTTP {
|
|
|
|
|
|
|
|
class Job : public Core::NetworkJob {
|
2022-02-02 18:51:55 +03:00
|
|
|
C_OBJECT(Job);
|
|
|
|
|
2020-05-05 08:17:40 +03:00
|
|
|
public:
|
2023-02-10 03:00:18 +03:00
|
|
|
explicit Job(HttpRequest&&, Stream&);
|
2022-03-03 21:35:10 +03:00
|
|
|
virtual ~Job() override = default;
|
2020-05-05 08:17:40 +03:00
|
|
|
|
2023-02-09 01:05:44 +03:00
|
|
|
virtual void start(Core::Socket&) override;
|
2022-02-02 18:51:55 +03:00
|
|
|
virtual void shutdown(ShutdownMode) override;
|
|
|
|
|
2023-02-09 01:05:44 +03:00
|
|
|
Core::Socket const* socket() const { return m_socket; }
|
2022-02-02 18:51:55 +03:00
|
|
|
URL url() const { return m_request.url(); }
|
2020-05-05 08:17:40 +03:00
|
|
|
|
|
|
|
HttpResponse* response() { return static_cast<HttpResponse*>(Core::NetworkJob::response()); }
|
2022-04-01 20:58:27 +03:00
|
|
|
HttpResponse const* response() const { return static_cast<HttpResponse const*>(Core::NetworkJob::response()); }
|
2020-05-05 08:17:40 +03:00
|
|
|
|
|
|
|
protected:
|
|
|
|
void finish_up();
|
|
|
|
void on_socket_connected();
|
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 16:44:12 +03:00
|
|
|
void flush_received_buffers();
|
2022-02-02 18:51:55 +03:00
|
|
|
void register_on_ready_to_read(Function<void()>);
|
2022-12-04 21:02:33 +03:00
|
|
|
ErrorOr<DeprecatedString> read_line(size_t);
|
2022-02-04 13:49:59 +03:00
|
|
|
ErrorOr<ByteBuffer> receive(size_t);
|
2022-02-02 18:51:55 +03:00
|
|
|
void timer_event(Core::TimerEvent&) override;
|
2020-05-05 08:17:40 +03:00
|
|
|
|
|
|
|
enum class State {
|
|
|
|
InStatus,
|
|
|
|
InHeaders,
|
|
|
|
InBody,
|
2020-08-19 05:34:15 +03:00
|
|
|
Trailers,
|
2020-05-05 08:17:40 +03:00
|
|
|
Finished,
|
|
|
|
};
|
|
|
|
|
|
|
|
HttpRequest m_request;
|
|
|
|
State m_state { State::InStatus };
|
2023-02-09 01:05:44 +03:00
|
|
|
Core::BufferedSocketBase* m_socket { nullptr };
|
2022-10-01 18:11:36 +03:00
|
|
|
bool m_legacy_connection { false };
|
2020-05-05 08:17:40 +03:00
|
|
|
int m_code { -1 };
|
2022-12-04 21:02:33 +03:00
|
|
|
HashMap<DeprecatedString, DeprecatedString, CaseInsensitiveStringTraits> m_headers;
|
|
|
|
Vector<DeprecatedString> m_set_cookie_headers;
|
2022-02-11 22:25:15 +03:00
|
|
|
|
|
|
|
struct ReceivedBuffer {
|
|
|
|
ReceivedBuffer(ByteBuffer d)
|
|
|
|
: data(move(d))
|
|
|
|
, pending_flush(data.bytes())
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
// The entire received buffer.
|
|
|
|
ByteBuffer data;
|
|
|
|
|
|
|
|
// The bytes we have yet to flush. (This is a slice of `data`)
|
|
|
|
ReadonlyBytes pending_flush;
|
|
|
|
};
|
|
|
|
|
2023-03-06 19:16:25 +03:00
|
|
|
Vector<NonnullOwnPtr<ReceivedBuffer>> m_received_buffers;
|
2022-02-11 22:25:15 +03: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 16:44:12 +03:00
|
|
|
size_t m_buffered_size { 0 };
|
2020-05-05 08:17:40 +03:00
|
|
|
size_t m_received_size { 0 };
|
2021-10-16 21:17:18 +03:00
|
|
|
Optional<u32> m_content_length;
|
2020-05-12 01:25:10 +03:00
|
|
|
Optional<ssize_t> m_current_chunk_remaining_size;
|
|
|
|
Optional<size_t> m_current_chunk_total_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 16:44:12 +03:00
|
|
|
bool m_can_stream_response { true };
|
2021-04-11 23:17:33 +03:00
|
|
|
bool m_should_read_chunk_ending_line { false };
|
2021-06-29 00:10:18 +03:00
|
|
|
bool m_has_scheduled_finish { false };
|
2020-05-05 08:17:40 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|