>get data is insecure by nature so the whole page is insecure and no >warnings, as soon as you post you invoke the security.
No, no, no. POST data is *NO* *MORE* *SECURE* than GET data! Period. Okay, if you want to get picuyane -- A total idiot user can read the URL in their location bar, and a total idiot user can maybe figure out a way to munge it, and another total idiot, as webmaster, might build a web-site that lets something bad happen when that happens... And, technically, it's possible that the first total idiot user couldn't figure out how to forge a POST. However, calling GET "less secure" than POST for that reason is, like, the worst (best?) example of the well-debunked "security by obscurity" concept. It does not take a genius to forge POST just as quickly and easily as GET. "Hiding" your data by POST and thinking it's "more secure" is just plain foolish. POST data is *not* transmitted by any more inherently secure method. POST data is not significantly hidden from the end user. Unless you consider "View Source" as more tricky than reading the Location box in the browser... Which I'm just not willing to buy as "more secure". There is *NO* inherent technical superiority to a POST data for security purposes. >You probably have a >url on your page that is coming from an insecure server (http:// instead >of https://) This would be correct, except: He has no HTML page on the HTTPS:// URL. He has a PDF file. There can be no URL (images etc) on an HTML page that doesn't exist. The *real* problem, as I said, is that he's forcing the browser to open a blank window, and that blank window is given an HTTPS URL, and that blank window is taking that HTTPS URL as a "promise" that some HTML will be delivered securely. Then, the server responds, *not* with some securely-delivered HTML, but with some securely-delivered PDF data. The *browser* fires up the PDF application (or plug-in) but *STILL* has this browser window, hanging around, waiting for the promised securely-delivered HTML that never arrived, never will arrive, and cannot arrive, since only one (1) piece of content (the PDF) can be (*) delivered. Thus, by definition, the HTML data for the browser window was not transmitted securely, because no HTML was ever transmitted at all. * Technically, the HTTP protocol could use keep-alive and deliver *TWO* pieces of content: some HTML, *and* the PDF file. I have no idea if keep-alive and spewing out HTML and PDF would make the browser happy, but I'm willing to bet a dollar it would break a bunch more browsers, and an extra HTML page isn't the desired behaviour in the first place. Sorry for the repeat post, but I'm hoping I've stated it more succinctly this time... -- 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
