Wrapping Thrift up in protocols like HTTP can help alleviate some of the common issues and is a pretty reasonable thing to do.
But make no mistake, you still need to protect against the real issues. Even if you use HTTP, someone can still send a bogus request that *claims* to contain a 1GB string and trick the server into a huge allocation, even if the HTTP POST request is < 1K in size. Same goes for arguments about framing, etc. Even with a framed transport, nothing stops someone from intentionally sending a bogus frame size. You do need to make sure that your Thrift code is equipped to handle all these cases. -----Original Message----- From: Aron Sogor [mailto:big...@gmail.com] Sent: Sunday, April 25, 2010 5:50 PM To: thrift-dev@incubator.apache.org Subject: Re: Anyone using Thrift for public endpoints? It depends.. If you talking about raw socket protocol, sure you need some flow control and there is no such thing out of box. If run over HTTP that your HTTP container probably can limit the POST size... so you probably will not crash the server. Aron On Thu, Apr 22, 2010 at 1:24 AM, Mathias Herberts < mathias.herbe...@gmail.com> wrote: > Given that Thrift still suffers from crashes due to invalid data being > entered, I would not yet consider this a safe practice. > > Maybe after GSoC. > > But facebook does it for a test service IIRC. >
