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-04-07 14:36:10 +02:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <AK/HashMap.h>
|
2020-02-02 12:34:39 +01:00
|
|
|
#include <AK/String.h>
|
2020-02-06 15:04:03 +01:00
|
|
|
#include <LibCore/NetworkResponse.h>
|
2019-04-07 14:36:10 +02:00
|
|
|
|
2020-04-21 01:55:25 +04:30
|
|
|
namespace HTTP {
|
2020-02-02 12:34:39 +01:00
|
|
|
|
2020-04-21 01:55:25 +04:30
|
|
|
class HttpResponse : public Core::NetworkResponse {
|
2019-04-07 14:36:10 +02:00
|
|
|
public:
|
2020-02-02 12:34:39 +01:00
|
|
|
virtual ~HttpResponse() override;
|
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
|
|
|
static NonnullRefPtr<HttpResponse> create(int code, HashMap<String, String, CaseInsensitiveStringTraits>&& headers)
|
2019-04-07 14:36:10 +02:00
|
|
|
{
|
2021-04-23 16:46:57 +02:00
|
|
|
return adopt_ref(*new HttpResponse(code, move(headers)));
|
2019-04-07 14:36:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int code() const { return m_code; }
|
2020-05-12 19:07:42 +02:00
|
|
|
const HashMap<String, String, CaseInsensitiveStringTraits>& headers() const { return m_headers; }
|
2019-04-07 14:36:10 +02:00
|
|
|
|
|
|
|
|
private:
|
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
|
|
|
HttpResponse(int code, HashMap<String, String, CaseInsensitiveStringTraits>&&);
|
2019-04-07 14:36:10 +02:00
|
|
|
|
|
|
|
|
int m_code { 0 };
|
2020-05-12 19:07:42 +02:00
|
|
|
HashMap<String, String, CaseInsensitiveStringTraits> m_headers;
|
2019-04-07 14:36:10 +02:00
|
|
|
};
|
2020-02-02 12:34:39 +01:00
|
|
|
|
|
|
|
|
}
|