I interpreted it as a visual cue to remind you where you left off when you return to the page after following a link. It's not particularly slick and doesn't seem to always work right. But I appreciated the novelty, effort, and creativity in trying to solve that problem.
It claims HTTP/1.1 "is inherently insecure". This seems like hype, and indeed the countdown is to when some guy gives a talk - it's a promotional website for that guy.
What appears to be the issue is that HTTP/1.1 (as defined in RFC 2616) is ambiguous, and differing server implementations have differing interpretations, leading to security bugs - great, we can fix those bugs. We already obsoleted RFC 2616 and wrote RFC 7230 and RFC 7231 to eliminate this class of attacks, provided implementations follow it. It appears everything listed so far is servers/proxies that don't follow RFC 7230.
I suppose it does raise the question: do you know what your HTTP client/server's behaviour on ambiguous requests is? It would be nice to have a comprehensive test suite to find out.
The bullet hell minigame on the page is super distracting
I interpreted it as a visual cue to remind you where you left off when you return to the page after following a link. It's not particularly slick and doesn't seem to always work right. But I appreciated the novelty, effort, and creativity in trying to solve that problem.
Well that's a view from the Go world, but it's the first that I've heard of :
https://http1mustdie.com/
Should be interesting, and worth keeping an eye on. Only a week away.
It seems somewhat overblown.
It claims HTTP/1.1 "is inherently insecure". This seems like hype, and indeed the countdown is to when some guy gives a talk - it's a promotional website for that guy.
What appears to be the issue is that HTTP/1.1 (as defined in RFC 2616) is ambiguous, and differing server implementations have differing interpretations, leading to security bugs - great, we can fix those bugs. We already obsoleted RFC 2616 and wrote RFC 7230 and RFC 7231 to eliminate this class of attacks, provided implementations follow it. It appears everything listed so far is servers/proxies that don't follow RFC 7230.
I suppose it does raise the question: do you know what your HTTP client/server's behaviour on ambiguous requests is? It would be nice to have a comprehensive test suite to find out.