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
Content-Dispositioninformation, both when it is specified in the HTTP header and when it is specified in
metatags 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:
In addition, I've set it so that the HTML generated by Mentat as an error page includes the following
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:
|FF3||pass (uses the filename in subsequent 'save' operation)|
|MSIE7||pass (filename information not used)|
|Op9.6||pass (filename information not used)|
|Saf3||pass (filename information not used)|
|Konq||pass (filename information not used)|
|Chrome||pass (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
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.