Summary
Environment: Windows Server 2016, IIS 10, ASP.NET webforms site, Wildcard SSL/TLS Certificate, IIS URL Rewrite 2.1 (MS supported download)
Goal: a) Determine and resolve the root cause(s) of the issue, b) [preferred] Get the two failing features working without users having to change settings on their browser, c) get the two failing features working, period, without first-time-processing issues on ubiquitous browsers (Chrome, FF, Edge, IE, Safari, Opera).
Issue Summary: Two of the site features i.e. downloading files and displaying SSRS reports fail with a first-time-processing error or fail entirely, depending upon the browser, with the SSL certificate bound to the site. Subsequent attempts to execute these features within the same browser window succeed in most cases. Various browsers fail in different ways and some don't fail at all depending upon the browser in question. Please bear with me as I try to provide details below.
NOTE: Both features work fine without the SSL certificate in the mix.
I have scoured the Internet for a solution to no avail and would be very grateful for any assistance on this.
Details
I have a client with an ASP.NET Webforms site containing file download and SSRS report display features. Users must be logged in to access these features. Sadly, the original developers implemented a rudimentary, homegrown approach for authenticating users i.e. it's not a "formal" authentication framework but, rather just a simple comparison of the provided username/password pair to the values stored in the database ... no formal authentication tokens are set to my knowledge ... could this be part of the issue?
Both of the aforementioned features have been working flawlessly for years using all current, major browsers. My client recently purchased a wildcard SSL/TLS certificate which I installed on the production IIS instance and configured the appropriate site bindings. In case this matters, the site is also using URL Rewrite with a basic rule in the web.config to modify all HTTP protocol requests to the HTTPS protocol.
All aspects of the site work fine with the SSL certificate in place except file downloading and SSRS report displaying. Current versions of Chrome and Firefox [Windows], and Mac browsers (I don't have first-hand access to a Mac environment) are exhibiting errant behavior. IE 11 (go figure) appears to be the only browser with no issues whatsoever. I have not tested Edge as I don't have access to that browser version.
File Downloading
The site has a feature that allows logged in users to download files from the site.
Chrome
Chrome displays a first-time-processing error "Failed - Network error" shown in the download status bar at the bottom of the browser. Clicking the chevron in the error message and choosing the "Resume" option from the context menu completes the download but, any attempt to open (double-click) the zip archive from its actual folder location results in the following error message: "Windows cannot open the folder. The Compressed (zipped) Folder '{path}' is invalid." Analyzing the zip file in a hex editor reveals that it contains the web page source code and not the intended file download. Repeating the file download operation in the same browser window works fine (culminating in a successfully downloaded, valid zip archive of files) and all subsequent file download attempts also succeed with no further issues for the remainder of the life of that browser instance. If the user closes their browser (all Chrome instances must be closed) and then re-opens Chrome navigating to the site, the browser, again exhibits the first-time-processing error and then works fine from then on for the remainder of the life of that browser window.
NOTE: All instances of the Chrome browser must be closed to reproduce the issue a second time. If the user leaves even one Chrome instance open on their computer and then navigates to the site using a new browser window and retries the file download, there are no issues. Perhaps Chrome is caching some kind of an authentication token? I am intentionally shying away from using the term "session" as the behavior does not appear to be session related. Opening a new tab within Chrome (after experiencing the aforementioned first-time-processing behavior) and navigating to the site (which culminates in a new session) does not exhibit the issue.
Firefox
Firefox displays a "Secure Connection Failed" error message when trying to download files from the site. All subsequent attempts continue to fail. This differs from Chrome's first-time-processing only behavior. Modifying the Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
Mac Browsers
Mac users report that file download attempts appear to succeed but attempts to open the zip archive culminate in the Mac environment thinking that the zip archive is password protected. NOTE: There is no explicit assigning of a password to the zip archive in the code that processes the download request. No users in Windows environments report this behavior.
SSRS Report Display
The site has a feature that allows logged in users to display a PDF document created at runtime from SSRS. The PDF displays directly in the browser window (as opposed to immediately initiating a download operation).
Chrome
Chrome displays a similar first-time-processing error when the user attempts to display an SSRS report. The browser displays the following error message: "Error Failed to load PDF document." The error message has a "Reload" button which culminates in the report displaying successfully. All subsequent attempts to display reports in the same browser window succeed with no further issues. The first-time-processing behavior is, again, experienced when the user closes and re-opens Chrome to the site, and retries the report display.
NOTE: It is interesting that in Chrome with either feature (file downloading or SSRS report display), once the user has experienced the first-time-processing issue with either feature, then the other feature works fine with no issues for the life of that browser instance. Example: User opens new Chrome instance, navigates to site, and attempts to download files. The file download will fail the first time. Immediately attempting to display a report succeeds ... and vice versa.
Firefox
Firefox displays the same "Secure Connection Failed" error message as was the case with the file downloading feature. Modifying the same Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
I am trying to generate pdf on clicking on url for different invoices on front end, using httphandler in asp.net web forms in the back end. The pdf generates well for all the invoices except for one, ON LIVE environment.
It opens a dialog box saying:
"Adobe Reader could not open '_XYZ__.pdf' because it is either not a supported file type or because the file has been damaged (for example, it was sent as an email attachment and wasn't correctly decoded)"
While , when I try to replicate the same on my Dev / test enviroment , all the pdfs generate properly for all the invoices.
Hence, I am unable to debug the issue on Live. How do I solve it and what could be the reason. Please guide.
Thanks
i am facing one problem from the last 25 days onwards ..
Ie. i publish one web site it is having 30 forms local source code working all forms
local server IIS7 working fine like source code
But the problem is at client server i.e also IIS7 out of 30 forms 3 forms are i am not able to open after press the menu
It is showing content controls are not allowed inside the tag..some error message.. three forms are showing the same message..
May i know what should i do..
Some body suggested some problem in coding tags ..i don't know how to solve the problem..
but i had observed
3 days on words strange thing was happens
while building also error is comming
plz have a look on below link
http://www.megafileupload.com/en/file/471108/Error-JPG.html
it is showing three erros
i said three forms are not able to open that 3 forms are showing errors
if i open the error contained design page
http://www.megafileupload.com/en/file/471109/Error1-JPG.html
after doing some changes in Source code
Removing last tag again again build it
I can build it successfully but in client server..it has the same problem.
How can i solve this problem?
I have written my first asp.net website and I'm ready to deploy. I've followed this tutorial to the letter in order to test first and all seems to proceed without any hitches or errors. However, the webpage gives a blank page with nothing rendered, only
<html><head><style type="text/css"></style></head><body></body></html>
All the files seem to have deployed correctly and I can see them in C:\inetpub\wwwroot\Test Webpage and if I attempt to run using inetmgr I get the same.
Can anyone advise what the problem(s) might be? Below are some screenshots of IIS if it helps but will post up more info if needed.
We are trying to open an existing excel file (2003) from server location in a web page and save it again in the same location using following syntax.
Set ExcelReportApp = CreateObject("Excel.Application")
ExcelReportApp.Workbooks.Open("http://bocntgcasd10/AppPortfolioCatalogrnd/Templates/DatabasesList.xls")
It executes properly with out showing any error, but not showing any page i.e. web page is blank with DONE status.
Please let me know how to import or open the files (Temple) in my web page.
Thanks!
Your question is a little ambiguous as to where the code you've posted is actually running.
If the code is running server-side I don't know why you wouldn't expect a blank web page, you aren't actually sending anything to the client.
If the code is running client-side you should be getting an error in script because this sort of operation is most likely blocked the browser (in IE you will see the small yellow warning triangle at the bottom left in the status bar). Again that would result in a blank web page.