SSL problem returning PDF file...

[Wayne Brantley]

Here is the test case:

Create a new asp.net project.

put a file - test.pdf in the web application directory.
add a a button and a hyperlink to webform1.aspx
The hyperlink - simply links to the pdf.
The button - simply opens the pdf, reads the data and writes it to the
response object - code below.

All works just fine.

Now, enter the problem. Change the url to be secure (change to https).
The hyperlink works as expected.
Upon clicking the button you get a message box saying 'this page contains
both secure and unsecure items' Would you like to display the unsecure
items - you can choose yes or no.

No matter what you choose, the pdf page displays properly and works fine -
you just get that annoying message.

Button click code:

FileStream fs=File.Open(MapPath(".")+"\\test.pdf", FileMode.Open);
try{
BinaryReader reader = new BinaryReader(fs);
try{
byte[] result = null;
//note in this test case, I have used a pdf file that is like 27k in size,
so this 32000 byte read is just for simplificatoin...
result=reader.ReadBytes(32000);
Response.Clear();
Response.ContentType="application/pdf";
Response.OutputStream.Write(result, 0, result.Length);
Response.End();
} finally{
reader.Close();
}
}finally{
fs.Close();
}

I created the above example just to show the problem. I actually ran into
the problem when trying to show the PDF returned from ReportingServices
webservice, but simplified it down to this.

How do I get rid of this warning message?


Wayne Brantley

 

[Steven Cheng[MSFT]]

Hi Wayne,

Thanks for your posting. Regarding on the problem you mentioned, I've
checked our internal document and did find that this is a known issue of
the IE. In fact, the problem is declared as below
========================
When using POST over HTTPS to access a server script that streams back a
PDF file,
users are prompted with the secure/insecure warning dialog - i.e., IE does
not
regard the PDF as secure content
Problem occurs on IE 6.0 sp1
========================

And currently it seems haven't been fixed yet. If you do want to avoid this
warning message, I'm afraid one workaround is to use Response.Redirect to
redirect to the pdf file directly rather than use code to stream it.
Please feel free to let me know if you have any concerns on this or if
this workaround is not suitable.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Wayne Brantley]

Can/Will this problem be fixed in IE? Like I said in my email, I am
delivering a report form SQL Server Reporting Services, so there is not a
real PDF file - nor and I going to temporarily stream the pdf to some file
and redirect them to that file.

The only workaround I can think of is after they fill out the form and press
submit, I could to a server.transfer or response.redirect (passing the post
parameters) to a page that simply returns the streamed PDF - then the
content does not appear to come from a postback.

HOWEVER, the best solution is to know this problem is being fixed or has
been fixed and will be in the next service release for IE or a security
patch for IE......

Wayne

 

[Steven Cheng[MSFT]]

Hi Wayne,

Thanks for your followup. Yes, I know that redirect directly to the pdf
file is not a good approach, and since you're retrieveing the pdf stream
from reporting service, that'll involve more troubles. Currently I'll
consult some further experts on this to see whether there is any action
plans on this issue in the near future.
Also, I've done some tests on use Server.Transfer or Response.Redirect to
redirect to another page(which return the pdf stream) in the first page's
button post back event, but unfortunately that didn't work either.
And another available workaround is register a clientside script to
redirect to the page(which return pdf stream) when the user click button,
for example:

private void Button1_Click(object sender, System.EventArgs e)
{
string script = "<script language='javascript'>window.location.href =
'{0}';</script>";
Page.RegisterStartupScript("redirect",string.Format(script,"writefile.aspx")
);
}

I'll update you if I got any further infos on this. Thanks for your
understanding.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Wayne Brantley]

Well, the problem with the Javascript event, is I need the 'posted data' in
order to determine what parameters to pass to report server. So
redirecting is also not very workable.

I get the impression from you that this is not considered a 'bug'. I would
like a definitivie workaround/fix for IE as soon as possible. Please let
me know who I can contact to discuss why this issue is not being addressed.

This is going to become an even bigger issue in the future with
ReportingServices. Currently I guess they get around it by supporting query
string only for parameters to run a report!!!

 

[Steven Cheng[MSFT]]

Hi Wayne,

Thanks for your followup. Yes, I can understand your concerns on the
problem since you need to provide infos to reporting service to retrieve
dynamic pdf stream and the issue of the IE on loading pdf over https
really make this very awkward. From the further consulting, currently the
dev team seems have regarded this problem as a existing issue , but haven't
any better means. The better workaround maybe :
======================
During the postback, dynamically create a temp pdf file (use sessionID or
time and datestamp for the file name, then send a response.redirect to the
client to send it directly to the new pdf file.

We can delete the temp files later during Session_OnEnd, or have a program
or service run every so often that deletes the older temp files.
======================

In addition, if you do feel this one is an urgent issue that need a
definite resolution, I suggest you try contacting the MS PSS to work on
this issue. Please feel free to let me know if you have any further
concerns or anything else we can help. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Wayne Brantley]

I contacted M$ PSS and they have recreated the bug - opened a new report and
are working on a fix.

Thanks for your help....

 

[Steven Cheng[MSFT]]

Thanks for your followup.

Have a good day!

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)