> @@ -267,7 +267,7 @@
> @PUT
> @Path("/{container}/{name}")
> @ResponseParser(ParseETagHeader.class)
> - @Headers(keys = "X-Object-Manifest", values="{container}/{name}")
> + @Headers(keys = "X-Object-Manifest", values="{container}/{name}/")
What the `X-Object-Manifest` header means is 'when somebody GETs this blob
return the contents of all the blobs whose names start with the value of
`X-Object-Manifest`'. If `{name}` contains a slash that's OK, and it would have
been before my change. What is a problem is if an unrelated blob is added that
starts with the value of `X-Object-Manifest`. By adding the trailing slash to
`X-Object-Manifest` I reduce the likelihood of this happening, but it could
still happen - see https://issues.apache.org/jira/browse/JCLOUDS-250 for an
idea for a more bulletproof fix.
Another reason for adding the trailing slash is that it's what the examples
I've seen do
(http://docs.openstack.org/trunk/openstack-object-storage/admin/content/direct-api-management-of-large-objects.html
and
http://www.rackspace.com/blog/rackspace-cloud-files-now-supporting-extremely-large-file-sizes/),
and by doing what the examples do we reduce the chance of interoperability
problems. For example, if a blob storage provider incorrectly implemented
`X-Object-Manifest` as 'when somebody GETs this blob return the contents of all
the blobs whose names start with the value of `X-Object-Manifest + "/"`' then
we'd still interoperate.
By the way, the code that actually uploads the chunks is in
`org.jclouds.openstack.swift.blobstore.strategy.internal.SequentialMultipartUploadStrategy`
and it constructs the chunk names as `key + PART_SEPARATOR + part` where
`PART_SEPARATOR = "/"` so it is safe to add the trailing slash here (because it
will always be present in the names of chunks uploaded by jclouds swift).
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/121/files#r5919717
