Meta bug for secure context developer experience improvements.

The real problem "little guy" developers face with secure contexts and development is their cobbled-together "local server". Providing an easy-to-configure local server that serves files off of a local disk, and an easy-to-generate local certificate would go a long way toward solving the developer experience. It is a pain in the neck to configure Apache or IIS to run locally, and they bog down the local machine. On the other hand, there will be some "big guy" developers that need all the facilities of Apache or IIS, but presumably they have more resources and knowledge of server configuration, and have development servers available. For example, I develop using a Python HTTP server as my local server. It was not at all obvious how to configure it to do HTTPS, but I finally did. And then it was not at all obvious how to configure it to handle multiple requests simultaneously (which caused certain features of Chrome to hang the server), but then I finally found the right Google query and bug reports and comments to get me past that. I deploy to Apache, but am no Apache expert for running it on my own machine. I finally figure out how to upgrade my self-signed certificate to use something more secure than SHA-1, to quiet the thousands of warnings being spewed to the web console. None of this stuff is straightforward to the web developer that isn't also an IT administrator, and searching out all the pieces to put together to get it to work was time-consuming, even though once each piece was found, it wasn't terribly hard to perform the necessary steps. So a light-weight server that supports multiple simultaneous requests, CGI, serves from a CWD, and comes with a tool to generate a modern self-signed certificate (maybe even generating its own internally on first use), would go a long ways towards enabling the "little guy" to be able develop comfortably using a secure context instead of complaining bitterly that secure contexts get in the way of development. I did a survey of "light weight" server tools when I got stuck hanging my server trying to experiment with web apps in Chrome (which seems to have the lead in supporting same, hopefully Firefox will catch up soon). All the ones I found had some limitation that prevented it from being useful... one didn't support CGI, one supported CGI but only in cgi-bin, one seemed to support everything I needed, but was a library that had to be invoked from a self-written main routine, in a language I don't use, etc. So I was extremely happy to finally stumble across a comment telling me how to get my Python HTTP to do multiple requests.

I didn't emphasize in comment 1 that having this stuff be well-documented is key. It would also be handy to have easily installable CGI plugins... I suppose PHP is popular enough to be one of them, and WordPress another. Personally I use a Python back-end, although it is invoked from the Python server via CGI so the environment is a bit more like when it is invoked from Apache via CGI. I should mention node.js... that was easy to get running on my machine, but the cheapo web hosting services don't provide it, so it isn't really an option for "little guy" developers on the low end of the spectrum. And the other problem with low-end deployment is the extra charges for certificates and private IP addresses to support the certificates. There needs to be a solution for using HTTPS with shared IP addresses, so that web hosts can't offer teaser rates for HTTP, and quadruple them when you add private IP address and HTTPS.... today, the only solution for that is to redirect from one's own HTTP domain, to the host's HTTPS domain: instead of http://www.mydomain.com/... you wind up with some atrocious thing like https://www.cheapo-web-hosting.com/~accountname/...

I won't answer to all your points but this one: > There needs to be a solution for using HTTPS with shared IP addresses, This is possible for some time [1], the support is quite good now. [1] https://en.wikipedia.org/wiki/Server_Name_Indication

The "little guy" isn't your only concern here. What about the "big guy" that has server-infrastructure with load-balancing and HTTPS termination at the load-balancer. Local dev builds will run over plain HTTP in that situation. Depending on what tech stack and frameworks are in use it can be quite a pain to configure solutions to run with HTTPS locally, and without when deployed. You can solve that easily enough though: offer a way to white-list domains.

@Julien - thanks, I had heard of SNI. I guess the issue is whether the shared host is configured for that. Will investigate. @r.otten - interesting. I'm "little guy" enough that I never thought about the case you mention, and while I can understand the situation and concern, the big guy should be able to configure a solution to have a (copy of) the load-balancing front end in front of the development server: testing in any other way might be useful for some things but until tested with the load-balancing front end in place, would not test everything, so deployment of something not tested with the front end in place would be risky, especially if configured differently regarding HTTPS.

@glenn It's not a deployed internal testing environment that's the issue. The issue is with doing development work on a web solution and needing to run it locally on the workstation of the developer. Just having 'localhost' white-listed would solve the base problem. (Is it already? I think this is what Chrome does, atleast...) However, just that is not enough. Sometimes third-party software your solution relies on a domain name and won't accept localhost. What you eventually end up with to make that work is adding a host mapping for something like `local-dev.example.com` to `127.0.0.1` and accessing the locally running site like that. This is why a configurable white-list is a must.

Using any sort of localhost solution when testing a mobile site would require porting a proxy to each mobile operating system. Would Apple allow it?

@damian Android has a reverse proxy as part of recent versions ADB, so the Android device can be connected via USB to the host running a localhost server, and everything works. So I'm not sure what kind of proxy you are talking about porting, but maybe there are two possible proxy options.