Re: [PATCH installer v3 26/38] common: http: allow passing custom headers to post()

Christoph Heiss
2026-04-15T08:53:51Z

Thanks for the review!

On Tue Apr 14, 2026 at 2:13 PM CEST, Lukas Wagner wrote:
> On Fri Apr 3, 2026 at 6:53 PM CEST, Christoph Heiss wrote:
>> Add an additional parameter to allow passing in additional headers.
>>
>> No functional changes.
>>
>> Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
>
> [...]
>
>> +///
>> +/// # Returns
>> +///
>> +/// A tuple containing
>> +/// * The body contents, as returned by the server
>> +/// * The content type of the response, if set in the response headers
>> +pub fn post(
>> + url: &str,
>> + fingerprint: Option<&str>,
>> + headers: header::HeaderMap,
>> + payload: String,
>> +) -> Result<(String, Option<String>)> {
>
> Maybe a custom type for the response would be a bit nicer here, instead
> of the tuple?

Yeah, makes sense, I'll change it for v4. At the very least, it makes
the whole thing a lot more self-documenting/less opaque.

[..]
>
>>
>> /// Information about the system boot status.
>> #[derive(Serialize)]
>> @@ -536,11 +537,7 @@ impl PostHookInfo {
>> .map(|v| {
>> // /proc/version: "Linux version 6.17.2-1-pve (...) #1 SMP ..."
>> // extract everything after the second space
>> - v.splitn(3, ' ')
>> - .nth(2)
>> - .unwrap_or("")
>> - .trim()
>> - .to_owned()
>> + v.splitn(3, ' ').nth(2).unwrap_or("").trim().to_owned()
>> })
>> .unwrap_or_default();
>>
>> @@ -640,16 +637,12 @@ impl PostHookInfo {
>> sockets.insert(value);
>> }
>> // x86: "flags", ARM64: "Features"
>> - Some((key, value))
>> - if key.trim() == "flags"
>> - || key.trim() == "Features" =>
>> - {
>> + Some((key, value)) if key.trim() == "flags" || key.trim() == "Features" => {
>> value.trim().clone_into(&mut result.flags);
>> }
>> // x86: "model name", ARM64: "CPU implementer"
>> Some((key, value))
>> - if key.trim() == "model name"
>> - || key.trim() == "CPU implementer" =>
>> + if key.trim() == "model name" || key.trim() == "CPU implementer" =>
>> {
>
> These seem to be unrelated changes caused by your auto-formatter, maybe
> split these out into a separate patch?

Yes, definitely, they should not have slipped it! Probably happened
somewhere during rebasing.