all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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(&copy_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")?,
> 





  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal