 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / JScript / August 2005document.open with non-html content
Hi group I have this issue, which is driving me nuts. On one page (A) I gather some options to generate content (a PDF document). In script I do a window.open(url) passing the options for generating the PDF as request params. The window does open, but it gives me an error, that the page cannot be opened for some DNS or hostname reasons I have done the exact same with plain HTML content and it works great, which leads me to think that it might be the PDF content. However, I have tried this in Firefox, and the PDF plugin loads and displays the document. But in IE, I can't get it to work. I don't think it is a popup-blocker issue. HTTP headers on the response is set up as: Content-type = "application/pdf" Content-disposition = "inline; filename.pdf" Cache-Control = "no-cache" I have tried with Content-disposition as "attachment", too.. Same result. The "funny" thing is: When I do a serverside forward to the exact same URL (the one generating the PDF and streaming it back to the response) it works!! But not, if I open it scripting a window.open(url) Here's the code (watch out for linebreaks) contenttype = document.getElementById('contenttype').value; processtype = document.getElementById('processtype').value; url = '/myurl?prepare=true&contentType=' + contenttype + '&processType=' + processtype; printWindow = window.open(url, 'printWindow','toolbar=yes,location=yes,directories=yes,status=yes,menubar=yes,scrollbars=yes,resizeable=yes,width=700px,height=600px,screenX=0,screenY=0'); Anyone has any ide, hint, tip...anything? Thanx in advance Regards Henrik Hi group Just wanted to let you know that I found a solution to the problem: Use the <embed> tag. I did, and it works great. Snip: <embed src="<URL generating the PDF doc>" type="application/pdf" width="100%" height="100%"> This seems to be a IE specific problem, as all other browsers I tested can handle it the "normal" way as described in an earlier thread. It has to do with the way IE requests a web resource (got it from one of the docs I found). It appers, that IE sends more than one request to get the resource, when it is not plain HTML (seems so), and that's why the stream get corrupted and IE can't figure out the content type. Maybe because of IE's built-in content sniffing. When I get the ressource with the embed tag it all works great. Streamed right back to the browser and the PDF plugin loads and shows the document. I thought I would share my newly found results with the group. I mean, that's what newsgroups are for, right? Regards Henrik http://websolver.blogspot.com Hello, Possibly, you could also do a window.open with some fake document that has only the code to change document.location of the newly-created window to the URL of your generated PDF file. Seems to me the EMBED solution may have some drawbacks as it's an ActiveX control in this case not an ActiveX Document as in case of navigation, right? So main menus and toolbars of the embedding may not be shown in case of such an approach … (H) Serge Hi Serge > Hello, > > Possibly, you could also do a window.open with some fake document that > has only the code to change document.location of the newly-created > window to the URL of your generated PDF file. I have tried several combinations of document.location, window.url, window.href, whatever all with the same negative results. > Seems to me the EMBED solution may have some drawbacks as it's an > ActiveX control in this case not an ActiveX Document as in case of > navigation, right? So main menus and toolbars of the embedding may not > be shown in case of such an approach … Dunno if I understand what the problem is. The Adobe Acrobat control is itself a plugin (ActiveX maybe I don't know). Main menus of IE is controlled through window.open. Basically what I do is this: - Script a window.open width the URL of the PDF generator - Generator server side code, checks for IE, and forward to a page with the Embed tag, which src attribute is set to the generator. - On second request (from embed tag) generator "senses" this, and knows that it is now the time to stream the content right back to the browser. - All other browsers only do first step. "Henrik Gottig" wrote : > HTTP headers on the response is set up as: > Content-type = "application/pdf" > Content-disposition = "inline; filename.pdf" > Cache-Control = "no-cache" .............................. > Basically what I do is this: > - Script a window.open width the URL of the PDF generator [quoted text clipped - 3 lines] > that it is now the time to stream the content right back to the browser. > - All other browsers only do first step. I had similar problem with IE and found that it's because of some headers in HTTP response : Cache-Control: no-cache, must-revalidate Pragma: no-cache So try to exclude Cache-Control = "no-cache" Also in some old versions of IE & Acrobat reader URL must be ended with ".pdf" http: ...........?a=b&c=d&dummy=.pdf What about <embed> in IE, it's really so. Simply open any pdf in IE and enter "javascript:alert(document.documentElement.outerHTML)" in address bar to see how IE wraps it. HTH Hello, AI> What about <embed> in IE, it's really so. Simply open any pdf in IE AI> and AI> enter AI> "javascript:alert(document.documentElement.outerHTML)" AI> in address bar to see how IE wraps it. IE does not use EMBED to wrap the PDF documents that are opened as a whole Web page or local file. There's no "document" object at all in this case. Executing a javascript command in the address bar shuts down the PDF display. The Internet Explorer Browser hosts a Shell Doc View ActiveX control as its main client space (SHDocVw.dll), which is capable of loading and displaying an ActiveDocument object approproate to the provided content. In case of a Web page, it's the MSHTML ActiveDocument object (mshtml.dll), for Office Word Documents, it's an ActiveDocument of the Microsoft Office Word, for PDF it's some special ActiveDocument as well (at least, for some of its versions — they're changing the model from time to time, so your solution is version-dependent). The document object is provided by the ActiveDocument currently loaded into the shell window, so there's no DHTML document if there's no Web page, but there are word document properties & methods, or something similar from the PDF component, in the respective cases. Moreover, the JScript support is not a feature of the browser on its own. It's provided by the MSHTML ActiveDocument, so you simply have no JScript support if you load something else bu a Web page. That's reasonable, as anything that you may execute as script (but for the address bar, of course) is usually included in the content handled by the MSHTML. I do not actually know who executes the JScript code entered into the address bar. (H) Serg Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.