dotcloud/hipache — pull request #130 by dmp42 (2014-04-21 17:26:45+00:00)
Title: Experimental SNI support

Read #129 for the background.

I reimplemented node `https` server so to be able to have **asynchronous** SNI callback support. This I call `https2`, which is pretty much a lightened node `https`. I still rely on `tls`, `net` and `http`.

One question needs to be solved before merging this:
* are we ready to take that kind of risk? (eg: departing from node `https` implementation)

If yes, we need to decide what we want for SNI.

If you want to test it:
* check out this branch
* start hipache with `NG_HTTPS` env variable set to whatever true (eg: `NG_HTTPS=true ./bin/hipache -c something`)
* now it looks-up into the folder ./config/certs/ and try to find a `.cert` and `.key` files named after the SNI, then loads these files asynchronously
* wether I find them or not, this is stored in a cache that never expire (looked-up only once, then)

So, do we want:
* expiring (LRU?) on certs / keys
* Redis storage for certificates?

Generally, how do you see Hipache SNI, if you have a use case?