Exactly, things like that. A lot of thrift fields also have encodings for sizes. So a malformed request might make the server think, "I am about to receive a string that is 5429823549082 bytes in length," or "I am about to receive a list of 1M elements."
Many of our protocol implementations already allow you to set limits on sizes of things to prevent these particular issues, but they are generally not things that have been deeply vetted. By comparison, most open web-server implementations are full of loads of code that sets limits on request sizes, memory use, malformed inputs, connection lifetimes, timeouts, request time, etc. It really is quite a long list of considerations. All things that certainly can be made robust in Thrift, but no one's done a deep audit... so, caveat emptor. Cheers, Mark -----Original Message----- From: Richard Salz [mailto:[email protected]] Sent: Tuesday, April 26, 2011 6:13 PM To: [email protected] Subject: Re: use thrift to create an interface from ruby to C++ and use it as webservice Alex <[email protected]> wrote on 04/26/2011 08:44:22 PM: > What is it about them that makes it unsuitable for public use? I am > currently running a Thrift server (Ruby) in a production environment > for remote clients. First, note that Mark was referring to the C++ servers, not Ruby. But that doesn't mean the Ruby stuff is "safe" either. It could be; nobody's making any comment on it. In general, there is a huge amount of work involved in moving a server from a friendly behind-a-firewall environment, where clients make mistakes but aren't malicious, and putting that code into the Internet, where there are enough malicious folks out there to cause you trouble. For example, suppose someone open a TCP connection and then lets it sit idle, or sends a byte every five seconds. How many of those clients do you need before your server becomes unavailable, perhaps costing you revenue? And so on. :( /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/
