> The constraint that ruined everything: It has to work on enterprise networks.

> You know what enterprise networks love? HTTP. HTTPS. Port 443. That’s it. That’s the list.

That's not enough.

Corporate networks also love to MITM their own workstations and reinterpret http traffic. So, no WebSockets and no Server-Side Events either, because their corporate firewall is a piece of software no one in the world wants and everyone in the world hates, including its own developers. Thus it only supports a subset of HTTP/1.1 and sometimes it likes to change the content while keeping Content-Length intact.

And you have to work around that, because IT dept of the corporation will never lift restrictions.

I wish I was kidding.

> So, no WebSockets

The corporate firewall debate came up when we considered websockets at a previous company. Everyone has parroted the same information for so long that it was just assumed that websockets and corporate firewalls were going to cause us huge problems.

We went with websockets anyway and it was fine. Almost no traffic to the no-websockets fallback path, and the traffic that did arrive appeared to be from users with intermittent internet connections (cellular providers, foreign countries with poor internet).

I'm 100% sure there are still corporate firewalls out there blocking or breaking websocket connections, but it's not nearly the same problem in 2025 as it was in 2015.

If your product absolute must, no exceptions, work perfectly in every possible corporate environment then a fallback is necessary if you use websockets. I don't think it's a hard rule that websockets must be avoided due to corporate firewalls any more, though.

Back when I had a job at a big old corporation, a significant part of my value to the company was that I knew how to bypass their shitty MITM thing that broke tons of stuff, including our own software that we wrote. So I could solve a lot of problems people had that otherwise seemed intractable because IT was not allowed to disable it, and they didn't even understand the myriad ways it was breaking things.

> And you have to work around that, because IT dept of the corporation will never lift restrictions.

Unless the corporation is 100% in-office, I’d wager they do in fact make exceptions - otherwise they wouldn’t have a working videoconferencing system.

The challenge is getting corporate insiders to like your product enough to get it through the exception process (a total hassle) when the firewall’s restrictions mean you can’t deliver a decent demo.

Request URL has a query parameter with more than 64 characters? Fuck you.

Request lives for longer than 15 sec? Fuck you.

Request POSTs some JSON? Maybe fuck you just a little bit, when we find certain strings in the payload. We won't tell you which though.

They even break server-sent events (which is still my default for most interactive apps)

Corporate IT needs to die.

> it likes to change the content while keeping Content-Length intact

thanks, i had repressed that memory

At the same time, enterprise is where the revenue is.

>And you have to work around that, because IT dept of the corporation will never lift restrictions.

Because otherwise people do dumb stuff like pasting proprietary designs or PII into deepseek