Safari Content-Disposition info bug

As a loyal Safari user, I am a great admirer of the work done by the WebKit team on today's fastest and most standards-compliant HTML rendering engine. A couple of years ago, however, I reported a bug which remains unfixed to this day. The bug is the following:

WebKit basically ignores filename parameters in Content-Disposition information, both when it is specified in the HTTP header and when it is specified in meta tags within an HTML document.

Let me give you an example from this very website -- the 404 error notification of a non-existent or missing page. The Mentat content management system, which was designed by myself, includes the following code for delivering error notifications:

print "Status: $status\n";
print "Pragma: no-cache\n";
print "Cache-Control: no-cache\n";
print "X-Robots-Tag: noindex\n";
print "Content-Type: text/html\n";
print "Content-Disposition: inline; filename=\"error.html\"\n";
print "Content-Length: " . length($body) . "\n\n";
print $body; 
exit(0);

As you can see, this is fairly standard HTTP header stuff. The Content-Disposition line is correctly formatted and is properly received by Safari, as seen below in SafariStand's information window:

safari content disposition header info

In addition, I've set it so that the HTML generated by Mentat as an error page includes the following meta tag:

safari content disposition meta tag

Although it is clear that Safari correctly registers the information delivered here, it is not made use of at any point. And what, one might ask, is the point of providing Content-Disposition filename information, either in the HTTP header or in an HTML meta-tag, if it is then blithely ignored by the browser?

Selecting "Save As..." from within Safari results in a suggested filename title which consists of the contents of the title tag, with an appended .html suffix. The filename parameter that I have specified does not seem to enter into things at all.

Now, perhaps one might wish to override the document filename and provide a more human-readable and/or informative title -- but surely this should be up to those serving the content rather than the browser itself? Still, Safari is here only one of many criminals. According to this report, of all major browsers, only Mozilla Firefox respects the Content-Disposition filename in subsequent save dialogs:

Test Results
FF3pass (uses the filename in subsequent 'save' operation)
MSIE7pass (filename information not used)
Op9.6pass (filename information not used)
Saf3pass (filename information not used)
Konqpass (filename information not used)
Chromepass (filename information not used)

While it is perhaps understandable (if not wholly forgivable) to ignore the filename parameter when presenting an interface for saving files to the end user, the same should most certainly not apply in the Safari Web Inspector. If Safari has received the Content-Disposition filename information and is aware of it, it should know that the intended name of the file in question is contained therein. But alas, even in the Web Inspector, Safari still resorts to determining file names by chopping off the last component of the path. A request for http://sveinbjorn.org/blabla -- which is just a pretty URL-rewrite for a messy-looking CGI-request to mentat.pl -- should result in Safari receiving a document identified by both its header and an additional meta-tag as a file named error.html. Instead, what we get is a file named blabla.

safari content disposition inspector

While all of this may seem a bit pedantic, since Content-Disposition filename specification is not, as far as I know, a widely used feature, it should still be in the spirit of the WebKit project to make sure Safari makes optimal use of the information it receives about downloaded documents.

I see, for example, that I am not the only one to have stumbled on this problem.