I was wondering - isn't part of the problem that there is no way for a
user to handle these issues, that they are handled in the Thrift library
layer, so to speak?
Suppose a user wanted to add the behavior: "abort if an RPC message is
going to allocate more than 1MB data". Can a user do this? Or will he
have to hack the library code?
Mark Slee wrote:
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 form 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.
