>> >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

Here's your fundamental problem:

By definition, the PDF file isn't supposed to be in a browser window *AT*

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

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

Reply via email to