3 ms·

Or we'll have new tooling which makes it simple to enable SSL locally. Dev and prod should be as similar as possible anyway.

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 ago
  A 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 ago
    Mostly 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 ago
  Browsers 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.
dnr 6y ago
I started using mkcert for this. It's trivially easy to use and fixes all the weird quirks of http vs https: https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/ https://blog.filippo.io/mkcert-valid-https-certificates-for-... https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
toomuchtodo 6y ago
This should be the user's choice, not Google's.
- OptionX 6y ago
  And its not, its the IETF since whats being discussed here is the IETF version not Google's. Is was their choice to adopt QUIC for HTTP/3 and standardized it. If you don't like the IETF then its another matter. Just point you pitchfork the right way.
  - toomuchtodo 6y ago
    "The Internet Engineering Task Force is an open standards organization, which develops and promotes voluntary (my emphasis) Internet standards, in particular the standards that comprise the Internet protocol suite." No one is twisting the arms of Google or browser/tooling implementers. Did I miss a flag where this can be disabled on the browser? If so, that's my fault! But if not, that's my point.

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 ago
A 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 ago
  Mostly 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 ago
Browsers 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.

dnr 6y ago

I started using mkcert for this. It's trivially easy to use and fixes all the weird quirks of http vs https: https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/ https://blog.filippo.io/mkcert-valid-https-certificates-for-... https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert

toomuchtodo 6y ago

This should be the user's choice, not Google's.

OptionX 6y ago
And its not, its the IETF since whats being discussed here is the IETF version not Google's. Is was their choice to adopt QUIC for HTTP/3 and standardized it. If you don't like the IETF then its another matter. Just point you pitchfork the right way.
- toomuchtodo 6y ago
  "The Internet Engineering Task Force is an open standards organization, which develops and promotes voluntary (my emphasis) Internet standards, in particular the standards that comprise the Internet protocol suite." No one is twisting the arms of Google or browser/tooling implementers. Did I miss a flag where this can be disabled on the browser? If so, that's my fault! But if not, that's my point.