Few days back I got called upon to track down mixed content warning coming from a page. The application went through a long QA cycle and nobody ever saw that warning message poping up. First thing I found out was that application was never configured for HTTPS (SSL) in QA environment. First big mistake commited by release and QA enginners. But thats besides the point. The applcation was ready for deployment in production.

The only reason for this warning message to popup is when your page is accessing resources from non-SSL site or locations. The person who was initially tasked to track this down did diligence on his part. He went though every single resource file (CSS and JS) that the page was refering to. He did not see any thing obvious.

When i got tasked with this problem, first question i asked the developer was did he use a sniffer to check if there was any non-HTTPS resource access going in the application. I came to know that they did not use any sniffer or analyzer to monitor the resource access. Then i fired up my hand dandy Fiddler analyzer and launched the application. First i did not see anything that will ring the bell. Only thing i could see was HTTPS Connect messages. Then i realize that this site is configured for secure access in production. I had to make one change in Fiddler to turn on decryption of HTTPS response. The moment i turned that on, I saw 404 errors coming from a missing image file. There was nothing else in the trace that was out of sequence. Then i looked at the response content generated by that 404 error. It was trying to access standard error page configured for 404 error in IIS. And that page is not configured for secure access. I dropped the missing image in application and DING DING!

Debugging this problem made me realize how important the following things are when you are debugging web applications

• Always have a HTTP monitor or analyzer like Fiddler on your development box.
• Always have access to web logs for your application to look for 404 kind of errors. This will come handy if you do not have HTTP monitor installed.
• Have custom error pages configured for your applicaiton