Uncontrolled Mutation: An Example of Inefficiency

I pruned /etc/apt/sources.list a bit tonight, because it annoys me when I have to wait for a lot of data just to answer the question, "So do I need to upgrade anything?"  Really, when a handful of updates are published, I should not have to get a fresh 4.6 MB copy of the entire multiverse package tree.

Since the scope of potential mutation is the entire index file, all clients only get file-level granularity for controlling the amount of data they download.

A New Way to Write Broken Perl

I called $cls->SUPER::new in a package constructor that was erroneously missing a base class, which issues the helpful diagnostic:

Can't locate object method "new" via package "The::Package::Name" at .../The/Package/Name.pm line 12.

So Perl says it can't find the method at the exact site of the definition, which is weird enough, but the real problem is triggered by the line with the SUPER call.  Once I added the use parent 'The::Parent'; line to the package, everything was fine.

This behavior was observed Perl 5.10.1 as presently available through the repository for CentOS 6.2.

AmazonS3 'headers' and 'meta' options in the PHP SDK

When you're using create_object, or several other methods of the AmazonS3 class, the $opts parameter often allows for both headers and meta keys.  Although headers is documented as "HTTP headers to send along with the request", it turns out that they are returned with the object (i.e. in the response) when that object is requested from S3.  In contrast, keys in meta are canonicalized, prepended with x-amz-meta-, and returned that way.

That is, if you want to upload filenames like "$id-$md5.pdf" but deliver them to the user as "ContosoUserAgreement.pdf" in the Save-As dialog, then headers should contain a Content-Disposition key with a value of attachment; filename="ContosoUserAgreement.pdf".

If you put it in meta instead, then the HTTP headers on retrieval will contain a x-amz-meta-content-disposition header instead, which will not be honored by the browser.

I found all this out by uploading something like 12,000 files with the wrong metadata.  I then wrote a script to fix it, which ran straight into the problem that update_object doesn't work, so you have to use copy_object instead.  Note that when using copy_object with 'metadataDirective' => 'REPLACE', you need to specify all the metadata you want, because it does what it says: it deletes all old metadata before adding the new metadata from the copy_object request, so that only the new metadata exists afterwards.