Bug #11563
closed
RadosGW regression: COPY doesn't preserve Content-Type
Added by Sylvain Munaut almost 9 years ago.
Updated over 8 years ago.
Description
When creating an object with an explicit content-type then copying it to another key, the returned content-type is binary/octet-stream instead of what was set.
That definitely used to work fine in 0.87, but is now broken in 0.94. (Found it when running our own regression suite before updating prod)
Files
- Project changed from Ceph to rgw
- Category deleted (
22)
- Affected Versions deleted (
v0.94)
Any news on this ?
Given that COPY is used when renaming objects (like if you do a streaming upload but you want the name of the object to be a sha256 of the name), it's pretty annoying to loose the metadata ...
- Priority changed from Normal to Urgent
- Backport set to hammer
- Source changed from other to Community (user)
- Status changed from New to Can't reproduce
I cannot reproduce it on latest master.
also can't reproduce it on hammer
I just updated my build to the latest commit of the 'hammer' branch ( 3e8d60a80ce31860eac76a1f6489a35e1795a0c0 ) and I still have the issue.
See the attached python script to reproduce (using boto, edit the top part with credentials and host/port).
And this is all using the S3 API.
Also tried pulling the commit for #11639 into my branch, didn't change anything. Also that commit is only for same bucket copy, but the content-type (and other metadata) should be kept even when copying to other bucket. (unless new metadata are provided in the COPY call)
- Status changed from Can't reproduce to 12
ok, managed to reproduce using your test. The key difference from my tests is that the object size also needs to be > 512k.
- Status changed from 12 to Fix Under Review
- Assignee set to Orit Wasserman
I cherry picked 1a6c3e760b1e2c1f4698009e70fd6cd1515ec722 over the recent hammer branch ( 3e8d60a80ce31860eac76a1f6489a35e1795a0c0 ) but the behavior didn't change.
Do I need any other commits ?
I tested it again now and it works for me (tested commit:e41d97c8e38bb60d7e09e9801c0179efe7af1734). However, note that there's an issue with your test script, that when you check for the copy key, you're doing b.new_key() instead of b.get_key().
You're right my bad, the fix seems to work.
When running my full test suite, it now passes correctly with the fix. Seems I made a small mistake when writing the small .py test above and changing it to get_key() works.
- Status changed from Fix Under Review to Pending Backport
- Assignee changed from Orit Wasserman to Loïc Dachary
- Description updated (diff)
- Assignee changed from Loïc Dachary to Orit Wasserman
Assigning Orit to record who was assigned the issue originally ( I still care for the backport of course ;-)
How is that not in 0.94.3 ?!?
Patch has been done for 3 month and it fixes a regression ...
Sorry for the time it takes. It fixed a regression but also introduced one, so we need to make sure everything works correctly now.
- Status changed from Pending Backport to Resolved
Also available in: Atom
PDF