+972 52-548-6969
The best features are the ones you never knew were thereYou can’t do everything
In the previous posts in this series, I talked about the kind of features that we build into RavenDB. Things that you never even notice making your life easier.
One feature we don’t have is doing HTTPS to HTTP downgrade. What do I mean by that? Assume that you have a RavenDB instance that is running using HTTP, and a client attempts to connect to it using HTTPS. Remember that we are assuming that the access it made on the same port. So the client wrote "https://my.raven.database:8080” instead of “http://my.raven.database:8080”.
If the other thing would happen, we would detect that and give a clear error to the user. But the other way around? We don’t do that, but why?
Well, the reasoning is very simple. If you connect to an HTTP endpoint using HTTPS, the first packet on the wire wants to do SSL negotiation. However, we don’t have a certificate that we can use here, so we can’t even start the negotiation process.
We could try generating a self signed certificate on the fly and answer the request with an error. But at this point, the client will likely already error at a low level because of the self signed certificate not being trusted.
Another point against implementing this feature is that HTTP endpoints typically become HTTPS, but rarely the other way around.
More posts in "The best features are the ones you never knew were there" series:
- (27 Nov 2017) You can’t do everything
- (21 Nov 2017) Unsecured SSL/TLS
- (16 Nov 2017) Protocol fix-ups
- (14 Nov 2017) Company culture and incentive structure
- (13 Nov 2017) Comfortable shoes & friction removal
Comments
Comment preview