Or you can tack on more filetype clues onto the URL.... http://whatever/myscript.pl/results.txt ; yes a slash works or http://whatever/myscript.pl?results.txt
This will run myscript.pl...that emits Content-type: text/plain The browser then sees results.txt in the URL and forces the result to be .txt This trick also sets the file's filename (if your cgi echos out an Excel csv file and click Save inside Excel inside IE). > -----Original Message----- > From: William A. Rowe, Jr. [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 1:14 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Metadata for .tar.gz > > [Suggestion, reply to docs@ and let's spare dev@ the bandwidth > since this is mostly an admin/user issue.] > > I almost forgot an 'extra' interaction... > > If we set up content-type application/x-tar with the proper > content-encoding of gzip we end up with even WIERDER > browser behavior... > > Consider that foo.tar.gz has those headers ... the type of > the file really is an x-tar that has been gzip compressed. > > So now the friendly browser takes foo.tar.gz and decides > that the file is really, really a .tar, but it only looks at the > last extension. That extension isn't .tar so it either; > > * truncates from the first period and adds .tar > * truncates from the last period and adds .tar > * appends .tar to the name. > > And furthemore the browser may; > > * unpack the .gz content so the value of any .md5 or .sig/.asc > associated with the original file is now meaningless > > Aren't user friendly tools way to helpful these days :-? > > I would *really* love to get feedback from the client developer > communities about how on earth an admin or web developer > should prepare for this. But I honestly don't have cycles to > engage the MozDev team or any others in such a discussion. > > Of course IE understands the Content-Disposition header. What's > sad is that header is from MIME mail RFC 1806, not HTTP. > > I'm almost ready to hack a module to add Content-Disposition > munging so that IE quits trying to save "myscript.pl" as a perl > script (when myscript.pl returns content-type text/plain or > application/octet-stream.) Only to make IE users shut up already > about their broken browser. (The hack: when responding with the > myscript.pl request as text/plain results, send this convoluted > header: Content-Disposition: inline; filename="myscript.txt" > which forces the browser to treat it, by filetype, as .txt output. > Since everyone else ignores such a bogus header, it should be > a mostly harmless hack.) > > One such thread on the Content-Disposition topic; > > http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1996q4/0048.html > > Bill > > > > > At 12:20 PM 2/4/2003, William A. Rowe, Jr. wrote: > >An answer to a user question (and a gripe from me since I've hit this > >problem myself on apache.org); > > > >> [the links] point to .tar.gz files, which exist. When they are clicked on, > >> however, they are being renamed to .tar.tar files. Any ideas? > > > >Renamed by the browser, not the server. > > > >Check in mime.types that we have content types for .tar *and* .gz. The > >default defines only .tar, so we return application/x-tar. If it included .gz, > >the *final* pathname element determines the mime type, which would > >be application/x-gzip. > > > >Almost makes you wish for application/x-gtar or something. You can only > >count on gnu tar to support tar -z. > > > >Anyways, because the content type is application/x-tar, and the browser > >sees the *final* extension is .gz, it is choosing to replace .gz with .tar or > >even adding another .tar (e.g., .tar.gz.tar which I've seen also.) > > > >Seems like the ASF needs to choose between removing application/x-tar > >or adding application/x-gzip in the default mime types. Sure, we have a > >general policy against adding x- extentions, but by adding one, we open > >ourselves up to problems. :-) > > > >Bill > >
