Bug 6 - Hard-coded limitation on Content-Length over connection-based transports
Summary: Hard-coded limitation on Content-Length over connection-based transports
Status: NEW
Alias: None
Product: resiprocate
Classification: Unclassified
Component: stack (libresip) (show other bugs)
Version: unspecified
Hardware: All All
: P4 enhancement
Assignee: Owner of all unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-08 15:09 CDT by Byron Campen
Modified: 2008-12-02 13:45 CST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Byron Campen 2007-10-08 15:09:21 CDT
For connection-based transports, as soon as the Content-Length header is parsed, a buffer is allocated with the capacity specified by the Content-Length header. Right now, this value is limited to a maximum of 10MB. We need to either:

A) Make this maximum size configurable.

B) Refactor so that we aren't allocating the entire buffer in one go. This will
allow a higher maximum, since the sender will actually need to send the bits to get us to alloc the memory. (Instead of just DoSing us by sending a big number in the Content-Length)

I think the proper solution is to do B.
Comment 1 Byron Campen 2008-12-02 13:45:48 CST
So, we have refactored to allocate the buffer piecemeal, but we are also putting a hard upper limit on what we are willing to accept. We should probably make this configurable, but it isn't as high a priority.