21–30 of 80 posts
Do http/2 and http/3 offer any benefits if they are only supported by the reverse proxy but not the underlying web server? Most mainstream frameworks for JS/Python/Ruby don't support the newer http standards. Won't the web server be a bottleneck for the reverse proxied connection?
Back in 2011, I was using it to learn API development by intercepting mobile app requests when I discovered that Airbnb’s API was susceptible to Rails mass assignment (https://github.com/rails/rails/issues/5228). I then used it to modify some benign attributes, reached out to the company, and it landed me an interview. Rest is history.
Do http/2 and http/3 offer any benefits if they are only supported by the reverse proxy but not the underlying web server? Most mainstream frameworks for JS/Python/Ruby don't support the newer http standards. Won't the web server be a bottleneck for the reverse proxied connection?
Earlier quoted context omitted.
I’m curious what about HTTP/3 is particularly advantageous with HTMX?
A common use case of HTMX is sending fragments when scrolling. Since http/3 uses udp to send the fragments, duplicate packet information doesn’t have to be sent. Kind of funny the newer protocol effectively works in the opposite direction of GraphQl.
Earlier quoted context omitted.
> mitmproxy is not a reverse proxy for any production purpose At a startup I was working on a few years ago, I set up mitmproxy in dev and eventually if memory serves right I also sometimes enabled it in prod to debug things. That being said, we did not have a lot of users. We had in fact very very few users at the time.
I’ve been patiently waiting for someone to write a howto that uses mitmproxy to transparently obtain acme certificates for any web servers that are behind it. I’d totally pay a cloud provider to just do this and forward requests to my port 80 or 443 with self signed certificates. Https+acme is already open to this attack vector, so why inconvenience myself by pretending it is not?
> Chrome does not trust user-added Certificate Authorities for QUIC.
Interesting. In linked issue chrome team says:
> We explicitly disallow non-publicly-trusted certificates in QUIC to prevent the deployment of QUIC interception software/hardware, as that would harm the evolvability of the QUIC protocol long-term. Use-cases that rely on non-publicly-trusted certificates can use TLS+TCP instead of QUIC.
I don't follow evolution of those protocols, but i am not sure how disallowing custom certificates has anything with "evolvability" of protocol ...
Anyone knows are those _reasons_?
It’s great to see that Mitmproxy is still being developed - it indirectly made my career. Back in 2011, I was using it to learn API development by intercepting mobile app requests when I discovered that Airbnb’s API was susceptible to Rails mass assignment ( https://github.com/rails/rails/issues/5228 ). I then used it to modify some benign attributes, reached out to the company, and it landed me an interview. Rest is…
Only slightly related ... > Chrome does not trust user-added Certificate Authorities for QUIC. Interesting. In linked issue chrome team says: > We explicitly disallow non-publicly-trusted certificates in QUIC to prevent the deployment of QUIC interception software/hardware, as that would harm the evolvability of the QUIC protocol long-term. Use-cases that rely on non-publicly-trusted certificates can use TLS+TCP inst…
Only slightly related ... > Chrome does not trust user-added Certificate Authorities for QUIC. Interesting. In linked issue chrome team says: > We explicitly disallow non-publicly-trusted certificates in QUIC to prevent the deployment of QUIC interception software/hardware, as that would harm the evolvability of the QUIC protocol long-term. Use-cases that rely on non-publicly-trusted certificates can use TLS+TCP inst…