I have an API that I want to be accessible only by HTTPS. I know I can use URL-rewrite to force a redirect, but don't want to install additional modules. I was wondering whether only providing an HTTPS binding would be a secure solution (in a way that HTTP connection would not be allowed).

enter image description here

Is it possible to somehow trick the server into accepting HTTP request with this kind of setup?

3 Answers 3


It is not possible to "trick" the server, but there are a couple of caveats here.

First, it is still possible to set up another site in IIS with a binding that will accept HTTP requests, so you need to be aware of the configuration of any other sites hosted on this server.

Second, this configuration means that if people attempt to visit the site directly or otherwise over the HTTP protocol, they'll simply get an error. Depending on your use case, this may be fine, and it's certainly the least complex option. If you have people accessing the site via a browser however, it's probably not. If it isn't you can (as you already know) set up an HTTP binding and redirect. This has the added advantage of preventing other sites from binding HTTP to this IP/host name, reducing the likelihood that a second site will erroneously serve the site over HTTP.

  • Thank you for the answer, it's API for developers to connect, so no big trouble with seeing an error in the browser, though it's still more user friendly to set up URL rewrite of course. It's a pity IIS does not support this out of the box (all http automatic redirect flag), hopefully in next versions :) Jul 21, 2016 at 13:48
  • @IlyaChernomordik Yeah, in that case I'd agree with you, having only an HTTPS binding definitely makes sense. As to redirecting HTTP to HTTPS, I'd agree it would be nice if that were a checkbox option, but it can still be done pretty easily! This answer is effectively what I use for my sites.
    – Xander
    Jul 21, 2016 at 13:56
  • HSTS preloading can go some of the way, too.
    – user
    Jul 21, 2016 at 14:32
  • @MichaelKjörling Yes, good point.
    – Xander
    Jul 21, 2016 at 14:47

No - if there is no http binding, IIS will not accept an HTTP request. On 443, it will attempt to negotiate a TLS/SSL (depending on configuration) connection, if it cannot, the connection will fail.


Relevant quote : " By enabling SSL in Microsoft® Internet Information Services (IIS) 7.5/7.0, the [webservers] communicate using authentication and encryption for all data transfers."

Allowing https to degrade to http would be a serious violation of the TLS standard.

As an aside, you will probably also want to consider which protocols you support - all SSL protocols and TLS 1.0 are considered insecure at this point (TLS 1.1 and 1.2 are still fine). https://support.microsoft.com/en-us/kb/187498#LetMeFixItMyselfAlways shows you how to limit down to TLS 1.1 and 1.2. However, note that older browsers may not support 1.1 and 1.2 (almost anything relevant now supports 1.0), so depending on your target audience, you may need to still support TLS 1.0 for awhile longer.

  • 1
    Yes, I know about protocol versions, thank you for you answer. Jul 21, 2016 at 13:34

HTTPS only is a bad idea if your site hosts public info, especially if that info is dynamically generated by a CMS. It makes ISP Internet caching and reverse proxy (such as squid/varnish) not work and that can lead to overloaded servers and exorbitant bandwidth usage. If you have a limited number of users this isn't a big deal but it will cripple your servers during large traffic spikes and lead to downtime unless you have a -lot- of computing resources.

  • I don't really agree. HTTPS is always a good idea and you have to protect you users. Wikipedia is HTTPS even though it's public as you say. Caching is your own responsibility and you have to make all you resources with proper headers and not rely on some things in between. Jul 22, 2016 at 8:00
  • You are funny lol
    – Neil Davis
    Jul 22, 2016 at 11:09
  • Why are you even posting a URL to something that is April's joke and says "it’s basically impossible to secure your applications — so why bother@". Jul 22, 2016 at 11:47
  • It was a joke, sorry, my way of admitting I was wrong with one regard. Content injection on public networks is a good enough reason to run SSL all the time. MITM can't easily be detected and if you are MITM on a public network, you can intercept a packet and inject malicious code. There's your argument for all SSL. It's the only one that's really valid.
    – Neil Davis
    Jul 22, 2016 at 13:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .