3 ms·

I'm a bit sad to finally see the death of HTTP/2 Push. It was a neat idea, with poor framework uptake that never really got the attention I think it could've be

by lol768 2y ago

I'm a bit sad to finally see the death of HTTP/2 Push. It was a neat idea, with poor framework uptake that never really got the attention I think it could've benefitted from. The .NET folks never bothered shipping it; there was a basic implementation in nginx. It was always hamstrung by lack of cache digests too. Chrome ultimately got rid of it with a justification partially along the lines of "nobody would notice anyway" and because re-architecting everything to use UDP (because that works great with NAT, doesn't it?) was apparently more important.

kstrauser 2y ago
I never had problems with UDP and NAT, but if that’s the thing that gets people annoyed enough to migrate to IPv6, I’ll shut my mouth and smile.
- LegionMammal978 2y ago
  I'd imagine that an IPv6 host behind a stateful firewall would have very similar issues with UDP connection tracking.
  - 01HNNWZ0MV43FF 2y ago
    It might require a firmware update but I see a clear text connection if here in the quic example https://quic.xargs.org/ https://quic.xargs.org/ Assuming that the IP port 4-tuple is not enough I never have trouble on my networks with QUIC or other popular udp protocols like WebRTC or DNS
    - LegionMammal978 2y ago
      I also haven't had any issues with UDP behind an IPv4 NAT, nor behind an IPv6 firewall. I'm just suggesting that at whatever rate people do have issues with UDP behind an IPv4 NAT, people would similarly have issues behind an IPv6 firewall.
  - kstrauser 2y ago
    Perhaps the main difference is that the average IPv6-configured firewall device is newer than the average NAT device, having become common much later.