From: Hannes Laimer <h.laimer@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>, pbs-devel@lists.proxmox.com
Subject: Re: [PATCH proxmox] s3-client: copy_object: always set Content-Type header
Date: Thu, 12 Mar 2026 13:45:53 +0100 [thread overview]
Message-ID: <2552a0ad-ade6-404a-8010-a09f6b82e3a3@proxmox.com> (raw)
In-Reply-To: <cdd85106-5fff-40cd-8816-669568179e35@proxmox.com>
On 2026-03-12 13:39, Christian Ebner wrote:
> On 3/11/26 10:56 AM, Hannes Laimer wrote:
>> Some S3 providers drop all source metadata, including Content-Type,
>> when using x-amz-metadata-directive REPLACE unless it is explicitly
>> provided in the copy request. This caused s3_refresh to fail with
>> "missing header 'content-type'" on such providers when fetching
>> objects moved via copy_object.
>>
>> Setting Content-Type explicitly is a no-op for providers that already
>> preserve it, so this is safe regardless of the provider.
>
> This should further state that it only acceptable to set the header
> unconditionally here, since the current s3 client implementation does
> set it unconditionally as well. Which however raises the inconsistency
> as mentioned below.
>
>>
>> Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
>> ---
>> did notice this with RustFS, MinIO did not have that problem
>>
>> proxmox-s3-client/src/client.rs | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/proxmox-s3-client/src/client.rs b/proxmox-s3-client/src/
>> client.rs
>> index 81645716..baa8345e 100644
>> --- a/proxmox-s3-client/src/client.rs
>> +++ b/proxmox-s3-client/src/client.rs
>> @@ -602,6 +602,7 @@ impl S3Client {
>> .method(Method::PUT)
>> .uri(self.build_uri(&destination_key, &[])?)
>> .header("x-amz-copy-source",
>> HeaderValue::from_str(©_source)?)
>> + .header(header::CONTENT_TYPE, "binary/octet-stream")
>
> This should be `application/octet-stream` [0], there is no `binary/
> octet-stream` according to [1]. While checking this, I did notice the
> original Content-Type in put_object() is set to `binary/octet` which is
> also wrong. So both should be fixed and aligned.
>
thanks for taking a look, makes sense! Funnily enough, even this did fix
the problem, I guess it being set at all was enough :P
I'll send a v2, with this and the one you mentioned updated
> [0] https://www.iana.org/assignments/media-types/application/octet-stream
> [1] https://www.iana.org/assignments/media-types/media-types.xhtml
>
>> .header(
>> "x-amz-metadata-directive",
>> HeaderValue::from_str("REPLACE")?,
>
next prev parent reply other threads:[~2026-03-12 12:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 9:56 Hannes Laimer
2026-03-12 12:39 ` Christian Ebner
2026-03-12 12:45 ` Hannes Laimer [this message]
2026-03-12 12:48 ` Christian Ebner
2026-03-16 14:21 ` superseded: " Hannes Laimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2552a0ad-ade6-404a-8010-a09f6b82e3a3@proxmox.com \
--to=h.laimer@proxmox.com \
--cc=c.ebner@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox