Originally published at thomas-sutton.id.au
This is more for myself than the world (I keep forgetting it and have to look it up every time I need it), but it’s a blog post and it’s on the Third so it counts for [World Blogging Month][woblomo].
Exporting data is an important feature for almost any web-application, but it’s one that many implement poorly or skip all together. Most of my day job is focused on creating static-ish web-sites, but every now and again I need to gather and process data in ways that my normal tools can’t handle. When I do, I inevitably reach for CSV when it comes time to export data. Producing CSV is a potentially complex and messy business: there are so many different conventions for quoting and escaping that the name “comma separated values” is really the least important aspect of the whole thing.
That said, I normally don’t bother with any of that and just (being, of necessity, a PHP user):
<?php
echo implode(",", $values), "\n";
?>It’s probably just a bunch of integers anyway, so there won’t be any commas anyway.
After I’ve got that working, I need to force the browser to prompt the user to save the file other ways the clients — many not particularly computer literate — will get all confusified. Thankfully, the W3C have considered this (or the people who wrote the MIME RFCs, I’m not entirely sure which is the chicken and which the egg) and given us a mechanism to specify exactly this: the Content-Disposition header in HTTP/1.1.
A Content-Disposition header looks something like this (from RFC2183):
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";Like many headers, the value (the bit after the colon) can have several parts separated with a semicolon. The first part (attachment in the example above) tells the browser what to do with this content. “Attachment” indicates that this is an attachment, as opposed to content which ought to be displayed, and should be downloaded or indexed or whatever the client usually does with such things. The filename parameter tells the client the original filename associated with the content, generally so that the client can display the correct default in the whatever “save as” dialogue it displays to the user. The final parameter in the example specifies the date that the content was last modified, again so that the client can set the date on the file if it is saved.
Sending Content-Disposition is as easy as sending any other header with HTTP. In PHP, my code generally looks a little something like this (Notice that the filename parameter is quoted, as RFC2616 describes):
<?php
$filename = "thingo-". date('Y-m-d H:i') .".csv;
header("Content-Type: text/csv");
header("Content-Disposition: attachment; filename=\"$filename\""
?>After which, I’m ready to loop and echo away.
Alternatively, pretty much every browser out there will prompt the user to save a file with the application/octet-stream MIME type. Sending such a MIME type instead of a Content-Disposition header will save you a few dozen bytes and a function call which could — conceivably — go wrong, but it doesn’t specify a filename, so you’re liable to wind up with your script’s name (often something like export.php).
It’s important to note that, while it is widely implemented, the Content-Disposition header is not part of the HTTP standard and does have security implications (though these generally boil down to: some users are stupid and trust things that come through the intertubes).
Haskell FastCGI with Apache
It’s pretty easy to get started with Haskell web-applications using the [cgi][hs-cgi] and [fastcgi][hs-fastcgi] packages, but a little bit of extra documentation never hurt anything. What follows is a brief run-down of getting a Haskell FastCGI program compiled and working under Apache with
mod_fastcgi.[hs-cgi]:
[hs-fastcgi]:
Read More »