For the longest time (more than a decade) I ran a small company (< 50 employees) that fielded a video chat service. The whole thing revolved around a minor bug that just happened to be present in all major browsers.

All that time I thought: next week someone else is going to clue in to this, it is so obvious. But nobody ever did.

You can read more about it here:

https://jacquesmattheij.com/the-several-million-dollar-bug/

So I totally believe that the seed for the idea came from somewhere else.

And this is why when I recant an answer based on docs or rfc, I use the phrase "X should do Y, but I'd have to verify it by hand"

At this time, the first link in that story is bad:

https://jacquesmattheij.com/content/story-behind-wwcom-camar...

This seems to work:

https://jacquesmattheij.com/story-behind-wwcom-camaradescom/

Isn't this more to do with how TCP and the socket interface is implemented (or more accurately its intended semantics) than a bug in browsers? Not draining any inbound data on a new connection prior to sending my request doesn't sound like a bug.

Yes, that's the practical reason. But a browser could of course have implemented HTTP in the way described in the RFC, instead they all took the easy and obvious way out. That's also why the bug was present in all browsers that had marketshare, it was the obvious thing to do, it is not as if they independently made the same mistake, they independently decided that it wasn't important enough to implement the protocol to the letter.