views:

174

answers:

2

I have a web app which loads an arbitrary page or file into an iFrame.

Under some browsers, when pointing the iFrame's src to a css file, instead of displaying the css text, a "download/open file" prompt appears.

Is there any way to prevent this? I understand the valid security reasons for not downloading or opening a non-text file by default, but a css file or any text/* filetype should be safe enough (safer than HTML in fact!)

The css file's response header looks like the following:

Content-Type: text/css; charset=utf-8
Status: 304 Not Modified
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.4
Etag: "34b924980254e212b651bcae25da011e"
Last-Modified: Thu, 04 Feb 2010 11:01:59 GMT
X-Runtime: 0.11366
Server: nginx/0.7.62 + Phusion Passenger 2.2.4 (mod_rails/mod_rack)
Content-Encoding: gzip

200 OK

Now I know I could use XHR instead of an iFrame to get the text and then display it, but in this application the content could conceivably be anything, determined by the user, at run-time, rather than a pre-defined set of pages/files. And it needs to be in an iFrame rather than loading an XHR response into a div in the parent window as the loaded page may have some javascript which relies on the correct location string (such as analytics, ads, javascript-based blog/comment systems, etc).

Another other option would be XHR to work out the file type, then

  • set src attribute for iFrame if it's HTML, or
  • copy the response content into the iFrame if it's plain text
  • do nothing if binary file

The problem with that solution is that in the first case, I'd end up needing to send two requests rather than just one. The advantage is that I can ignore binary files outright, though in this application it is doubtful that the user will try to load anything other than a HTML or other plain text page into the frame.

I'm pretty sure there's not going to be a simple solution (if any at all), but there's no better place to ask than here, so.....

Edit 12-Feb-2010:

By the lack of answers, I'm assuming my original assumption is correct (no way to do this, if at all), thus the only solutions are either to ignore the problem altogether (not ideal), or use my suggested method of XHR to determine response type and only load into frame if HTML. Again, this is not ideal, but if the browser cached the XHR response, this would make things a little better, so:

Does anyone know whether a browser would usually cache an XHR response so if the same url was subsequently loaded into an IFRAME the cached version would be used? I realise this is browser and settings dependent, but would for example IE and Firefox with out-of-the-box settings do this?

A: 

For verbatim display of the file as plain text, I would just send it as

Content-Type: text/plain; charset=utf-8
ndim
It sounds like he might not necessarily have access to the server for this.
Andy E
This would work, but @Andy E is correct - I will not necessarily have access to the server. I will however only be loading pages/files from the same domain as the parent window, so the same-domain policy for iFrame window/document access and XHR would not be an issue, in case there's any trickery that can be applied in that regard....
Graza
A: 

Within your web app you could have a page (in whatever language you're using, assuming that you're not serving up solely static files) that takes a parameter which is the path of the file you want to view and then load that in the IFRAME

So rather than setting the IFRAMEs src to "somefile.css" (or whatever file it is), set the src to "FileViewer.php?filepath=/somefile.css" (replace .php with the language of choice), and then have the FileViewer page load the file from the filesystem and render it out but with a Content-Type set.

Rob
Thanks for the response, this would work if the server app was mine, but as in my comment on ndim's answer, I won't have access to server apps (aside from my own site) - I'm working on a script which people can add to their own sites. I could add your suggestion to my documentation, and this might be my only/best option, but I want to make deployment as simple as possible, so people using CMS' who don't have control over content headers can use it with minimal fuss. The page/resource being loaded will be user-driven, so even site authors may not have control over what is requested.
Graza
If you have no access to the server then XHR is pretty much your only option :)
Rob
Do you know whether a browser would usually (default settings, etc) cache an XHR response, to remove the need for another round-trip if I then determined that the content should be loaded into a frame?
Graza