2020-05-05 09:47:40 +04:30
|
|
|
/*
|
2022-03-03 11:35:10 -07:00
|
|
|
* Copyright (c) 2020-2022, the SerenityOS developers.
|
2020-05-05 09:47:40 +04:30
|
|
|
*
|
2021-04-22 01:24:48 -07:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-05-05 09:47:40 +04:30
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <AK/HashMap.h>
|
2020-05-12 02:55:10 +04:30
|
|
|
#include <AK/Optional.h>
|
2020-05-05 09:47:40 +04:30
|
|
|
#include <LibCore/NetworkJob.h>
|
2023-02-08 23:05:44 +01:00
|
|
|
#include <LibCore/Socket.h>
|
2020-05-05 09:47:40 +04:30
|
|
|
#include <LibHTTP/HttpRequest.h>
|
|
|
|
|
#include <LibHTTP/HttpResponse.h>
|
|
|
|
|
|
|
|
|
|
namespace HTTP {
|
|
|
|
|
|
|
|
|
|
class Job : public Core::NetworkJob {
|
2022-02-02 19:21:55 +03:30
|
|
|
C_OBJECT(Job);
|
|
|
|
|
|
2020-05-05 09:47:40 +04:30
|
|
|
public:
|
2023-02-10 01:00:18 +01:00
|
|
|
explicit Job(HttpRequest&&, Stream&);
|
2022-03-03 11:35:10 -07:00
|
|
|
virtual ~Job() override = default;
|
2020-05-05 09:47:40 +04:30
|
|
|
|
2023-02-08 23:05:44 +01:00
|
|
|
virtual void start(Core::Socket&) override;
|
2022-02-02 19:21:55 +03:30
|
|
|
virtual void shutdown(ShutdownMode) override;
|
|
|
|
|
|
2023-02-08 23:05:44 +01:00
|
|
|
Core::Socket const* socket() const { return m_socket; }
|
2022-02-02 19:21:55 +03:30
|
|
|
URL url() const { return m_request.url(); }
|
2020-05-05 09:47:40 +04:30
|
|
|
|
|
|
|
|
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 09:47:40 +04:30
|
|
|
|
|
|
|
|
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 17:14:12 +03:30
|
|
|
void flush_received_buffers();
|
2022-02-02 19:21:55 +03:30
|
|
|
void register_on_ready_to_read(Function<void()>);
|
2022-12-04 18:02:33 +00:00
|
|
|
ErrorOr<DeprecatedString> read_line(size_t);
|
2022-02-04 10:49:59 +00:00
|
|
|
ErrorOr<ByteBuffer> receive(size_t);
|
2022-02-02 19:21:55 +03:30
|
|
|
void timer_event(Core::TimerEvent&) override;
|
2020-05-05 09:47:40 +04:30
|
|
|
|
|
|
|
|
enum class State {
|
|
|
|
|
InStatus,
|
|
|
|
|
InHeaders,
|
|
|
|
|
InBody,
|
2020-08-18 20:34:15 -06:00
|
|
|
Trailers,
|
2020-05-05 09:47:40 +04:30
|
|
|
Finished,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
HttpRequest m_request;
|
|
|
|
|
State m_state { State::InStatus };
|
2023-02-08 23:05:44 +01:00
|
|
|
Core::BufferedSocketBase* m_socket { nullptr };
|
2022-10-01 18:11:36 +03:00
|
|
|
bool m_legacy_connection { false };
|
2020-05-05 09:47:40 +04:30
|
|
|
int m_code { -1 };
|
2022-12-04 18:02:33 +00:00
|
|
|
HashMap<DeprecatedString, DeprecatedString, CaseInsensitiveStringTraits> m_headers;
|
|
|
|
|
Vector<DeprecatedString> m_set_cookie_headers;
|
2022-02-11 20:25:15 +01: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 17:16:25 +01:00
|
|
|
Vector<NonnullOwnPtr<ReceivedBuffer>> m_received_buffers;
|
2022-02-11 20:25:15 +01: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 17:14:12 +03:30
|
|
|
size_t m_buffered_size { 0 };
|
2020-05-05 09:47:40 +04:30
|
|
|
size_t m_received_size { 0 };
|
2021-10-16 20:17:18 +02:00
|
|
|
Optional<u32> m_content_length;
|
2020-05-12 02:55:10 +04:30
|
|
|
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 17:14:12 +03:30
|
|
|
bool m_can_stream_response { true };
|
2021-04-12 00:47:33 +04:30
|
|
|
bool m_should_read_chunk_ending_line { false };
|
2021-06-29 01:40:18 +04:30
|
|
|
bool m_has_scheduled_finish { false };
|
2020-05-05 09:47:40 +04:30
|
|
|
};
|
|
|
|
|
|
|
|
|
|
}
|