thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slee <>
Subject RE: use thrift to create an interface from ruby to C++ and use it as webservice
Date Wed, 27 Apr 2011 03:11:23 GMT
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.


-----Original Message-----
From: Richard Salz [] 
Sent: Tuesday, April 26, 2011 6:13 PM
Subject: Re: use thrift to create an interface from ruby to C++ and use it as webservice

Alex <> 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 

And so on. :(


STSM, WebSphere Appliance Architect

View raw message