Bug #11563
closedRadosGW regression: COPY doesn't preserve Content-Type
0%
Description
- fix in master https://github.com/ceph/ceph/pull/4995
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
Updated by Samuel Just almost 9 years ago
- Project changed from Ceph to rgw
- Category deleted (
22) - Affected Versions deleted (
v0.94)
Updated by Sylvain Munaut almost 9 years ago
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 ...
Updated by Sage Weil almost 9 years ago
- Priority changed from Normal to Urgent
- Backport set to hammer
Updated by Sage Weil almost 9 years ago
- Source changed from other to Community (user)
Might be fixed by #11639
Updated by Abhishek Lekshmanan almost 9 years ago
Is this in the swift or s3 API? In swift API there was a backport to hammer for COPY that may be the cause for this (https://github.com/ceph/ceph/pull/4568)
Updated by Yehuda Sadeh almost 9 years ago
- Status changed from New to Can't reproduce
I cannot reproduce it on latest master.
Updated by Sylvain Munaut almost 9 years ago
- File issue-11563.py issue-11563.py added
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.
Updated by Sylvain Munaut almost 9 years ago
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)
Updated by Yehuda Sadeh almost 9 years ago
- 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.
Updated by Yehuda Sadeh almost 9 years ago
- Status changed from 12 to Fix Under Review
- Assignee set to Orit Wasserman
Updated by Sylvain Munaut almost 9 years ago
I cherry picked 1a6c3e760b1e2c1f4698009e70fd6cd1515ec722 over the recent hammer branch ( 3e8d60a80ce31860eac76a1f6489a35e1795a0c0 ) but the behavior didn't change.
Do I need any other commits ?
Updated by Yehuda Sadeh almost 9 years ago
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().
Updated by Sylvain Munaut almost 9 years ago
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.
Updated by Yehuda Sadeh almost 9 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Yehuda Sadeh almost 9 years ago
- Assignee changed from Orit Wasserman to Loïc Dachary
Updated by Loïc Dachary over 8 years ago
- 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 ;-)
Updated by Sylvain Munaut over 8 years ago
How is that not in 0.94.3 ?!?
Patch has been done for 3 month and it fixes a regression ...
Updated by Yehuda Sadeh over 8 years ago
Sorry for the time it takes. It fixed a regression but also introduced one, so we need to make sure everything works correctly now.
Updated by Loïc Dachary over 8 years ago
- Status changed from Pending Backport to Resolved