Unable to check/get object manifest

[markchalloner]

Hi,

There seems to be no easy way to check if an object is a manifest, i.e. get the value of the X-Object-Manifest header.

Manifests are used for large file uploads:
http://docs.rackspace.com/files/api/v1/cf-devguide/content/Large_Object_Creation-d1e2019.html
and "symlinks":
https://developer.rackspace.com/blog/simulate-symLinks-on-cloud-files/
They are defined by adding the X-Object-Manifest header, with a value of container/object/prefix
AbstractTransfer\createManifest()

DataObject\headerIsValidMetadata() uses the pattern ^X-Object-Meta- to filter the response headers, against which the X-Object-Manifest header fails.

Other headers e.g. Content-Type are set by DataObject\populateFromResponse()

Some ways I can see of allowing access to this information:

• Allow access to all the response headers by saving $response->getHeaders() into a property.
• Create is/get/setManifest methods and populate in DataObject\populateFromResponse()
• Relax the metadata pattern filter to X-Object-

The current workaround is to retrieve the headers from the API, but as this requires another trip to the the Rackspace endpoint, is inefficient:

$response = $object->getClient()
    ->head($object->getUrl())
    ->send();
$headers = $response->getHeaders();
$manifest = (string) $headers['X-Object-Manifest'];
echo $manifest;

Thanks

[ycombinator]

Hi @markchalloner, could you say a bit more about your use case behind this question? Specifically, what are you trying to accomplish in your application that requires:

1. checking whether an object is a manifest object, and/or
2. setting an object to be a manifest object.

Thanks.

[markchalloner]

Hi @ycombinator. Sure:

Background

• We host an analytics script file on the CDN.
• Our clients link their site to our system using a script tag in the HTML of their site (or tag manager).

Setting an object to be a manifest object

• Each time we deploy a new version it is saved as a new file and the "master" version symlinks to the latest version by using the manifest
• Each client has their own unique URL which by default symlinks to the "master" using the manifest
• At any point in the future, by updating the manifest we can give individual clients
  • an older version
  • a custom version
  • a blank version (e.g. for ex -clients not removing the tag)

Checking whether an object is a manifest object

• To show the status of a client script (where it is symlinked to) on our dashboard we read the manifest
• We avoid saving the status in a separate database as it is possible to update files with other clients (e.g. Rackspaces' own dashboard, curl, Cyberduck), thus invalidating the DB data.
• For the same reason we avoid saving the status in a separate cloud file (as well as adding complexity to the client and requiring an additional read/update)

Thanks

[ycombinator]

Thanks @markchalloner.

For your use case of "Setting an object to be a manifest object", we could provide a convenience method like $newScriptFileObj->createSymlink($masterFileName). It would create/update an object named $masterFileName (in the same container as $newScriptFileObj) and set the X-Object-Manifest header on this object to $newScriptFileObj->getName(). Would that work?

For your use case of "Checking whether an object is a manifest object", I think the best we could do is provide a method like $masterFileObj->getManifestHeader(). It would return the value of the X-Object-Manifest header on $masterFileObj if it exists or null otherwise. Would that work?

[markchalloner]

Hi @ycombinator

See PR. I implemented your suggestions, with some minor changes.

• I used symlink instead of createSymlink to fit in with other file manipulation functions (e.g. copy) naming conventions and avoid confusion over which file is the symlink and which the target.
• I used getManifest/setManifest to fit in with other header functions (e.g. getContentLength)

Cheers

[ycombinator]

Hi @markchalloner. Thanks for the PR. I've reviewed it and added a few comments inline with the code. Most of them are minor suggestions but this one is probably worth discussing: #565 (comment). Lets continue the discussion on the PR in the PR itself so its all in the same place with the code for context. Thanks again!

[ycombinator]

Fixed via #565.