[reSIProcate] Hardening the parser (what goes into 1.0?)

Byron Campen bcampen at estacado.net
Mon Aug 7 12:43:52 CDT 2006


> On 8/7/06 10:14 AM, "Byron Campen" <bcampen at estacado.net> wrote:
>
>>>
>> Given that the maximum size of a SipMessage is 64K, I think it is  
>> safe to assume that a UInt32 will be enough.
>>
>
> Where did that assertion come from? We’ve successfully passed 700MB  
> MESSAGE requests through a reSIProcate based product before. Don’t  
> confuse the MTU for a particular transport with the ‘maximum  
> message size’. :-) One thing that is worth considering; adding  
> explicit support for a maximum message size (settable by the stack  
> user). There are advantages to having a practical max.
>
> Secondly, there were some items you raised that I disagree with;  
> Content-Length is important, however when it is in disagreement  
> with the transport framing, I think we should believe the  
> transport. (SCTP/UDP/DTLS) in cases where we NEED the CL, then we  
> should pay close attention to it (and we do). Again, this is where  
> the concept of a maximum sounds reasonable. The parser should  
> consider returning reasonable results if the CL field is larger  
> than UINT32_MAX. (What would make sense? If the transport needs  
> framing, what would we do? The connection would need to read  
> UINT32_MAX+k bytes and we would have no mechanism to remember k.)
>
> Should we just close the connection when the CL is larger than our  
> max message size? Think about that...
>
> A


	I guess I mis-remembered that detail. But, does UInt32 sound like a  
reasonable limit? Or should we go with UInt64 so file transfers of  
larger than 4G can be carried out using a single sip request? Is any  
other implementation on the face of the planet likely to accept a  
Content-Length this large?

	As for whether Content-Length should be believed, I think we should  
at least make this behavior configurable.

Best regards,
Byron Campen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060807/56cd7914/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060807/56cd7914/attachment.bin>


More information about the resiprocate-devel mailing list