The Url : http://www.apache.org/dyn/closer.cgi/lenya/SOURCES/apache-lenya-2.0.2-src.tar.gz is a html page containing download links, not a tar archive. This is the "Unix source code" link at http://lenya.apache.org/docu20/installation20/download20.html If I call it with Safari 4.0.2 the page is not displayed, a download is initiated. With Firefox the page is shown correctly.
It would appear that Safari is basing its decision to download to be due to the file extension, and not the content type being returned. We are doing things the same way as Cocoon and Maven. Both Tomcat and HTTPD run their own cgi for mirror selection. I don't know if we want do do this to fix a Safari issue or not.
I think you do. First there are a lot of safari users and this causes each one of them grief. Second the presentation of the link violates expectations. I think that it is a reasonable expectation that a link on a site distributing software that shows a link to a 19M file gets you that file when you click on it. Consider, if you want to present a link to a set of mirrors, having a link that says "Select download from mirrors".
filed webkit bug report: https://bugs.webkit.org/show_bug.cgi?id=32262
Thanks for the comment Alan and for filing a bug against Webkit. I see that you were testing against POI, which is a different project with a slightly different download presentation than our project. However, the behavior is the same. I don't know what the best option for fixing it is. We want to use what infrastructure provides to us, which is causing the problem. I did do some testing just now from Windows XP, and Chrome behaves as expected for the reported content type. However, Safari 4.0.4 531.21.10 under XP does exhibit the odd behavior with the tar.gz link, but not the .zip link. It will be interesting to see what the Webkit devs have to say.
Here's the most likely cause from Alan's report: Request: GET /dyn/closer.cgi/poi/release/bin/poi-bin-3.5-FINAL-20090928.tar.gz HTTP/1.1 Accept-Encoding: gzip, deflate Response: Content-Encoding: gzip Content-Type: text/html So, by URL the browser thinks it is requesting a gzipped file, but it is also saying it will accept gzipped content from HTTPD. HTTPD sends it back the webpage gzipped and tells Safari that it is text/html. Safari sees the gz file extension and the gzipped content and ignores the Content-Type being sent back by HTTPD. So it downloads the page which is gzipped when Safari gets it.