[httptoolkit]

Anything attempting to proxy public Internet traffic and buffer the entire body at all times is in big trouble.

Either it has to have a very low body buffer limit and reject anything more (making it impossible to download any files through the proxy, or do anything similar) or it's trivially vulnerable to DoS where any client or server involved can crash the whole caboodle.

[voidwtf]

These are often devices or services used in the enterprise that do a lot of things that would surprise you, and just break applications willy nilly. We often have to request that exceptions be added for specific endpoints that use some of the aforementioned methods and are why I would shy away from them.

It's always fun to Response.Flush() in your server side application only to find the client receives nothing. They typically have limits to the amount they buffer, yes, usually pretty low. However, when all your trying to send is something as simple as "<script>Report.Progress(30)</script>" "<script>Report.Progress(35)</script>" that's part of some legacy code, you often see a sudden completion or jumps in the completion that are not representative of what's happened on the server side.

The best ones are the ones that try to handle mobile connections by holding open connections in weird ways, I'm talking about you NetMotion....