[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