Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our app interfaces with our web server using the HTTP components of WinINet, and in the past, we've had issues with this on certain corporate networks. For example, I couldn't append additional HTTP headers or their proxy would drop the requests. Things are working fine currently, but that's after a lot of difficult debugging.

We have now set up an SSL certificate and enabled our app to use HTTPS, and things seem smooth and great, but I am not convinced such a change is going to work out smoothly for these corporate networks. Would it be reasonable for a firewall to block SSL traffic? Are there any hidden 'gotchas' when it comes to SSL going through a proxy? Would it be worth it to configure the WinINet calls to fall back to HTTP if the HTTPS connection fails?

I'm just mainly interested in what I need to look out for and avoid, in the interest of making this as compatible as possible in the face of unseen network/firewall/proxy hurdles.

share|improve this question
Would it be reasonable for a firewall to block SSL traffic? - It does happen, if is reasonable or not is very subjective. Would it be worth it to configure the WinINet calls to fall back to HTTP - If you want reliable communication you should probably be prepared to try different methods. Firewall/filtering rules varies quite a bit between different networks. –  Zoredache Mar 10 '11 at 17:48
I'm a developer, not a network admin, so I just don't really know what to expect from the various networks out there. Just trying to get an idea what I need to be careful for. On that note, I'm not sure why this got moved to ServerFault, as it's about applications programming and I'm not in control of these networks. –  Doug Kavendek Mar 10 '11 at 19:11
This question isn't really about code meaning it isn't a good fit for stackoverflow, but it also isn't about system administration. I doubt this question really is a good fit on any stack-exchange site. Since every network may be different, and have different proxy and filters I doubt you'll find an answer better then the suggestion in my comment, that you need probably need to be able to support a few alternative methods. –  Zoredache Mar 10 '11 at 19:32
Certainly there's a lot of variety out there, and there's no way I'd cover all my bases, but surely other people have created programs that have had to play nicely with myriad network requirements, or at least know of good resources (books, links, etc.) to look into to even know what I can expect or watch out for. Perhaps that's too broad then. I'll just add more fallbacks and alternate methods where possible, but it's all just guessing at where the next unknown fire will spring up. –  Doug Kavendek Mar 10 '11 at 20:17
add comment

migrated from stackoverflow.com Mar 10 '11 at 17:37

This question came from our site for professional and enthusiast programmers.

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.