Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibHTTP/Header.h

55 lines
1.4 KiB
C
Raw Normal View History

LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
/*
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
* Copyright (c) 2024, Andreas Kling <andreas@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/ByteString.h>
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
#include <AK/StringView.h>
#include <LibIPC/Forward.h>
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
namespace HTTP {
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
// https://fetch.spec.whatwg.org/#concept-header
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
struct Header {
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
[[nodiscard]] static Header isomorphic_encode(StringView, StringView);
Optional<Vector<ByteString>> extract_header_values() const;
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
ByteString name;
ByteString value;
};
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
[[nodiscard]] bool is_header_name(StringView);
[[nodiscard]] bool is_header_value(StringView);
[[nodiscard]] ByteString normalize_header_value(StringView);
[[nodiscard]] bool is_forbidden_request_header(Header const&);
[[nodiscard]] bool is_forbidden_response_header_name(StringView);
[[nodiscard]] Vector<String> get_decode_and_split_header_value(StringView value);
[[nodiscard]] Vector<ByteString> convert_header_names_to_a_sorted_lowercase_set(ReadonlySpan<ByteString> header_names);
struct RangeHeaderValue {
Optional<u64> start;
Optional<u64> end;
};
[[nodiscard]] ByteString build_content_range(u64 range_start, u64 range_end, u64 full_length);
Optional<RangeHeaderValue> parse_single_range_header_value(StringView, bool allow_whitespace);
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
}
namespace IPC {
template<>
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
ErrorOr<void> encode(Encoder& encoder, HTTP::Header const& header);
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
template<>
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
ErrorOr<HTTP::Header> decode(Decoder& decoder);
LibHTTP+RequestServer: Add HTTP::HeaderMap and use for response headers Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...> everywhere, we now encapsulate this in a class. Even better, the new class also allows keeping track of multiple headers with the same name! This will make it possible for HTTP responses to actually retain all their headers on the perilous journey from RequestServer to LibWeb.
2024-06-09 11:28:37 +02:00
}
Reference in a new issue Copy permalink