Re: serving up blobs for download

Matthew, First of all thanks for your response. What I wanted to do is to have 2 separate links, 1 to VIEW the pdf, and 1 to DOWNLOAD the pdf. The reason for the 2 distinct links is because if the remote user DOES have a pdf viewer installed, clicking on the link will always start the PDF viewer, which does not have a way to save the file either. Right clicking the link will work, but the default filename it brings up in the file-save box is wrong because it picks up the script name which retrieves the file from the database, and not the actual filename. This forces the user to change the filename and add the appropriate .pdf file extension, so obviously that kinda sucks. So for my "view" link, I put the caveat that in order to VIEW the pdf, you have to have installed a PDF viewer. When the "view" link is clicked, the associated php script first sends the appropriate header for pdf (application/pdf), and then the file contents which are stored in a MySQL blob. Then the remote browser will recognize the content-type header and fire up the PDF viewer (if installed). So my "view" link works fine and just as I expected from a cross browser perspective. In regards to my "download" link, I have read in the content-type specifications that if a content type is NOT recognized, that the browser should then treat the content as "application/octet-stream", which is supposed to represent binary files. Netscape's default behavior is to initiate a file-save for this content-type, although it can be modified under Edit->Preferences->Navigator->Applications, just like you can do for any other types. So by sending the "application/octet-stream" header, or even any bogus unknown header (which should be treated as an octet-stream), Netscape will initiate the file-save box, and will also default to the file name specified using the "content-disposition" header. Everything works perfect. One click on the "view" link opens the pdf viewer (if installed) and one click on the "download" link opens the file-save box with the correct filename as default. However, IE doesnt recognize the application/octet-stream type and doesnt default to a file-save for unknown types. After poking around through the MS FolderOptions->FileTypes, I found that there is a content type of "application/x-msdownload". If I pass this header along with the content-header to specify the filename, then IE will ask if you want to download the file, as long as the file extentsion is .bin or .exe. If its not .bin or .exe, it doesnt recognize it. Apparantly IE forces both the content-type and extension to match. So anyways, although this does work, the user is still required to change the extension on the file from ".bin" to ".pdf", so obviously that still kinda sucks. I guess I was hoping that there would be a content-type specifically for "downloading". It just seems like a very logical content-type to have as a standard, doesnt it? Hopefully I have adequately explained what I am trying to achieve and why I want to do it this way. You mentioned that it is ultimately up to the browser as to how to handle the content, and that we have no control over that. Well isnt that exactly why we have standardized content-types in the first place, so that we CAN have some control over these things? By the way, thanks for the newsgroup, I will definitely look there. If there is a way to do this (exploit or not), then I guess that is exactly what I'm looking for... Rob Matthew Kendall wrote: > > "Rob Montgomery" <Robert.L.Montgomery@Home.com> wrote... > > I want users to be able to download (not view with a viewer) > > Users are _able_ to do this by right-clicking and selecting Save Target As, > or simillar. I suspect you mean that you want to _force_ a download to > happen. > > > pdf files which I have stored as blobs in MySQL, so the php > > script reads the blob into a variable, then does this: > > > > header("content-type: application/octet-stream"); > > header("content-disposition: filename=$filename"); > > echo $blob; > > > > With Netscape, this works great, the file save box opens and > > the filename to save as defaults to my variable $filename. > > > > The problem is that IE thinks it should be able to find a > > program to "view" the content-type of application/octet-stream. > > Netscape defaults to downloading unknown types, IE just gets > > confused. > > That's because you have deliberately confused it by giving it the wrong MIME > type for the file. The correct content-type for PDF is application/pdf. > > > Does anyone know how to handle that problem? Is there some > > other content-type which is specifically used for downloading? > > "How do I 'force' a download" is the most frequently asked question in > comp.infosystems.www.authoring.html. If you ask it there you will get lots > of bogus advice that will tell you about ways to exploit features of the > major browsers to cause the Save As dialog to be displayed most of the time. > However the real answer is that you cannot reliably 'force' the browser to > do anything. Ultimately, what the browser does with a received file is > entirely up to it, you have no control of it whatsoever (heck, you don't > even know what the browser is - it could be me, on the end of a telnet > connection - what does 'download' mean in that context?). And why would you > presume to know what action the user wants? He may want to view the file > within the browser or a helper application. If he wants to Save As a file he > is quite capable right-clicking and selecting Save Target As.