Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- http/https anomoly
January 7, 2008, 6:01 pm
rate this thread
i'd been prototyping a site and had a couple of reports that output in pdf
format. everything has been working fine so far. i added in some ssl last
night so that pages/scripts that set an $enableSecurity flag dynamically
change from http to https (avoids mixed security messages for things like
resource links, etc.). now, everything continues to work fine with the
exception of the pdf reports. there are no errors reported but no report
data is displayed.
to do further testing, i commented out the header()s call to set the content
type, disposition, etc. so that the raw pdf content would display in the
browser as text...just to make sure i was still getting output at all. turns
out, i'm still getting the content. i can also copy it from the browser,
save it to disk, and open it from there and see the report data just fine.
that leads me here. if you've run across this before or have an idea about
what the cause is...or, how i should approach further troubleshooting, i'd
really appreciate your input.
- C. (http://symcbean.blogspot.com/)
January 8, 2008, 4:21 pm
Re: http/https anomoly
Let me guess: you are using Internet Explorer. Internet Explorer has a
serious bug that causes it not to store anything if a no-cache header is
sent, not even if it calls another program to display the contents. So
it calls acrobat with data that IE refuses to pass. So acrobat starts
with data that is not there.
Let me do another guess: you are sending "do-cache" headers because IE
needs them to overcome the above problem, and you are using sessions.
In this case, you need to know that a session_start() call also sends
no-cache headers. This is poorly (if at all) documented and took me a
few months to find out as well.
So if you send headers like "Pragma-cache", send them *after* you use
the session_start() function.
Hope this helps,
Re: http/https anomoly
only tremendously! i'd read the article posted before and did as the fix
suggested without any luck!
yes, it is a company website and the company dictates IE (just what i have
to work with). and yes, the reports and rest of the site are secured and
some of that info is sessioned.
i'll let you know if it is solved, although if it works i'm not sure how to
pass the kudos along to you...other than saying thanks. :)