[ 
https://issues.apache.org/jira/browse/THRIFT-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733012#comment-16733012
 ] 

James E. King III commented on THRIFT-1324:
-------------------------------------------

[~belugabehr] this is a fairly easy fix to implement, enforcing the maxLength_ 
in the write() call of the TFramedTransport (and TFastFramedTransport).  
I like the notion of adding another TTransportException type indicating 
TOO_LARGE as suggested by the author, but you must implement it in every 
language if you are going to do it that way.

> TFramedTransport should enforce frame size limits on writes
> -----------------------------------------------------------
>
>                 Key: THRIFT-1324
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1324
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>            Reporter: Jim Ancona
>            Priority: Major
>              Labels: easyfix
>
> Currently TFramedTransport only enforces the maximum frame size when it 
> receives a frame larger than its configured maxLength_ value. so there is no 
> way to enforce a maximum frame size on the client. Because servers typically 
> deal with oversized frames by silently dropping them (see THRIFT-1323), 
> problems caused by oversized frames can be very hard to diagnose. Enforcing 
> the maximum frame size on writes would enable clients to detect the frame 
> size mismatch, assuming the client and server are configured with the same 
> value.
> Note that the exception thrown in this case should not be a generic 
> TTransportException--it should be either a subclass or a new 
> TTransportException.type_ value so that clients can distinguish the frame too 
> large error. This is important because most other TTransportException causes 
> reflect transient conditions where retry may be appropriate, but a too-large 
> frame will never succeed if retried.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to