3 ms·
Sure, I can create a self-signed certificate and copy it to my docker container and update the app’s config to use it and add it to the system’s certificate sto
by coddle-hark 6y ago
Sure, I can create a self-signed certificate and copy it to my docker container and update the app’s config to use it and add it to the system’s certificate store and then add it to every browser’s certificate store every time I need to run something over QUIC locally. And sure, maybe one day there will be a tool that can do a that automatically.
But like... why?
- gravypod 6y agoA lot of browsers already expect tls to enable specific features. I've had things break between dev and prod because of a lack of tls on the backend as well. It's also one of those things that once you sort it out it's no longer a problem. Like "why do I need to setup all this complex stuff to manage a dependancy? Just give me your source code and let me `gcc -o binary a.c b.c ....`" In reality once you solve a problem with an ergonomic solution and the solution improves your alignment with production and comes at no real cost it's a win/win/win.
- tialaramex 6y agoMostly browsers require Secure Context rather than TLS, so http://127.0.0.1/ http://127.0.0.1/ which is a secure context is fine.
- johncolanduoni 6y agoBrowsers have for some time behaveD quite differently when using HTTPS vs HTTP, particularly if you’re not navigating to precisely http://localhost http://localhost (e.g. if your dev environment needs multiple domains). In particular a lot of newer browser features will refuse to work, and you won’t be able to see any HTTP/2 specific issues (e.g. header case) either.