Tony Frasketi wrote: > Wiggins d'Anconia wrote: > >> Most browsers will provide this functionality if the return header is >> "application/octet-stream" rather than "text/html" or the like. In >> the case of IE you may have to fool the browser into thinking it is >> getting something different than it is based on the URL, because it >> likes to look there for a file extension to determine the file type too. >> HTH, >> http://danconia.org >> > Hi Wiggins > Thanks... I just tried putting these three lines in a .htaccess file in > a particular directory... > > AddType application/octet-stream .cgi > AddType application/octet-stream .txt > AddType application/octet-stream .htm > > Alternatively, I also tried AddType application/octet-stream .cgi > .txt .htm >
Interesting way to do it, not what I intended. Have you 100% confirmed that the header is being passed back correctly? I am not sure how Apache (or whatever web server you are using) handles setting the type, it might be finding it from somewhere else that is overriding it. There is a module for Firefox/Mozilla called "Live HTTP Headers" that will help you confirm what is being sent. What I was intending was to call the cgi script and rather than it printing the normal text/html header it would print the header directly, that way you are guaranteed to be operating the way you intended. > Using the Mozilla 5.0 Suite browser, I get the following results.... > > And then trried clicked on links to a .cgi file, a .txt file, and a .htm > file in that directory.... Only the .htm file automaticaly brought up a > 'Save as...' diaglogue box as I left clicked on the link to the .htm file > > when I clicked on the link to the .txt file, the contents of the .txt > file appeared in a Wordpad window. This is windows picking up the association based on the extension (probably), didn't you know it was smarter than you? ;-) > > When I clicked on the link to the .cgi file, the .cgi file was executed > and the results displayed in the browser window. > > One out of three right! > > ---------------------------- > Using the Microsoft IE 6.0 browser, I get the following results.... > > .htm file -> Displays the .htm file in browser window > .txt file -> Displays the .txt file in browser window > .cgi file -> Executes the .cgi script and displays results in browser > window > > zero out of three right! Yeh I suspect that is IE picking up on the URL extension. > > ---------------------------- > Using Firefox 1.0 browser, I get the following results... > .htm file -> brings up the 'Save as...' dialogue box > .txt file -> brings up the 'Save as...' dialogue box > .cgi file -> Executes the .cgi script and displays results in browser > window > The .cgi problem is probably because you have a handler setup for .cgi files that trumps the AddType call. What is the header printed by the .cgi file? It should be able to print its own header of "application/octet-stream" followed by the contents of a "file" and it should work correctly. > SO....................... Filefox wins by getting two out of the three > right! > > This method doesn't look very hopeful at this point! I know I have used this method before, and I have done so recently from within the context of a different web framework (specifically Interchange). As to your question about "Content-Disposition" it can be used to preset the filename that the user sees in the "Save as..." dialogue, but is again not standard, it is just convention and will depend on the browser supporting it, to my knowledge the major browsers[1] do support it. > Thanks again > Tony Frasketi Keep at it, I suspect you will get it to work... http://danconia.org [1] When I say major browsers I mean Mozilla (and variants, Firefox, etc.), IE (some recent version, probably newer than 4.x), Safari. I know there are others but I don't have a copy so can't say specifically how they act, they may work as well. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
