>> >The GET method form works fine, while the POST method (which is what I >> >need to use) pops up a message about the page containing both secure and >> >nonsecure data. >> > >> >WTF? >> >> Well, the new browser window opens, but you're loading a PDF, not HTML, so >> it's not really getting any data at all. The data it's not getting isn't >> secure, by definition, since there's nothing there. > >I'm not sure that I understand what you're saying here... I'm loading a php >file, that is creating the pdf on-the-fly. This php file is the one >receiving the POST data, not the window - or do I not understand?
Here is how HTTP usually works: 1. Browser requests URL, possibly in new window. 2. Server sends content 3. Browser displays content However, with a PDF, you have: 1. Browser requests URL, definitely in a new window 2. Server sends content, which happens to be a PDF file. 2a. Server does not send an HTML page 3. Browser has opened a new browser window, which is supposed to display an HTML page. 3a. Browser gets a PDF, which requires that it fire up a different application to view 3b. Browser has this nifty browser window, with no HTML to put into it, and it was supposed to get securely-delivered HTML, and it's pissed off you never securely-delivered the HTML you "promised" in 2. and didn't send in 2a. :-) >BTW... This example is not how the application works. It's just a test that >I used to narrow down the problem, and recreate in a controlled situation. >The real application needs to have the pdf file pop up in a separate window >using POST vars, which, in the application, is done using Javascript - but I >digress... Here's your fundamental problem: By definition, the PDF file isn't supposed to be in a browser window *AT* *ALL*. Yes, some funky-ass plug-in hacks will allow a PDF to be embedded inside of a browser window, but that's an add-on hack, long, long after HTTP protocol was defined. You've *TOLD* the browser to open up a new HTML window, and you've told it to expect some HTML sent securely, but the server isn't *sending* any HTML data *AT* *ALL* -- Just PDF data, which is going somewhere else. So, the *browser* sees this HTML window, you opened up, and it ain't got no secure HTML sent to it. Nothing. Nada. Zip. Again I say, GET RID OF THE TARGET="_blank" That's as close as you're going to get to having a new window with a PDF in it, for most surfers. >How is the POST data not 'secure' but the GET data is? How is it not secure >'by definition'? There's nothing where? Please expand. The server didn't send any HTML. There is no HTML to secure. If there's nothing there, nothing sent, it's rather difficult to send it securely. The PDF got sent, but that's not HTML, and it can't be displayed in the browser window, so the browser window never got nothing. But it was told, in advance, to expect some secure HTML. That secure HTML never arrived. No HTML arrived. Only PDF arrived. I think I need a picture/diagram and slow-motion animation to 'splain this properly... Try to imagine this happening in slo-mo. Browser is told: 1. Go get URL https://... 2. Put the HTML from that URL in a new window, and be sure it's secure. Server responds with PDF file, which essentially tells browser: 3. Go run the PDF application viewer thingie to view this data. Meanwhile, the browser has this HTML window, hanging around, waiting for securely-delivered HTML to arrive... It's definitely a browser "bug" that you can't tell it to open up a new window, for an HTTPS connection, and that content might not actually *be* HTML, but there *might* be a plug-in that will handle it in that window. Or, there might not be a plug-in, but so what? Unfortunately, that's not how the browsers are dealing with it, and I'm not sure they *can* deal with it properly, since there might *NOT* be a plug-in, so they might *not* get anything to put in that new window, so what are they supposed to do? Display a blank secure window? I'm not saying it's not a bug. I'm saying it's not a PHP bug, and it's a browser bug, and there's nothing you can do (unless you can convince both Bill and the Mozilla guys to fix it tomorrow) and the *BEST* way to get get kinda close to what you want is to lost the TARGET="_blank" It won't be a new window for people who did a PDF plug-in, but it will work the right way for everybody else... That was the best solution I could come up with this for this issue when I ran into it. Actually, you *MIGHT* be able to do this: 1. Force the new window to open up to some HTML page. 2. That HTML page, with JavaScript or META HTTP-EQUIV=REFRESH could *maybe* then suck down the PDF, and *maybe* you won't get that warning message... The crux of the problem is you are forcing a new browser window to open up, which is expecting some securely-delivered HTML, but it never gets no HTML, it just gets some PDF stuff, and it gets cranky about not getting the securely-delivered HTML you "promised". I just told the boss he couldn't have what he wanted, and we had to lose the pop-up window. But I hate pop-up windows anyway :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
