[Users] Bug in nathelper module or in the replace() function

[Bogdan-Andrei Iancu]

Federico Giannici wrote:

> Bogdan-Andrei Iancu wrote:
>
>> actually openser does not apply the changes (remove and add) on the 
>> received message buffer, but keeps some lumps with the changes - all 
>> this changes are applied and the end of the processing (from 
>> performance reasons).
>> In your case you have two operations at the same offset in the 
>> message - nathelper adding a remove and add lump and you (via 
>> replace) doing the same. There is nothing you can do about this.....
>
>
> So you are saying that if it happens that two separate and independent 
> modules for a pure chance modify the same header field, the resulting 
> message is corrupt???

yes.

>
> I think this is a GREAT limitation (I'd call it a bug) of the lumps 
> handling code...

it's not a limitation of the code, but of the concept. having a set of 
parallel changes starting from the same initial text may lead to 
inconsistency.....
that's a tribute for speed.....

regards,
bogdan

>
>
>
>> Federico Giannici wrote:
>>
>>> Daniel-Constantin Mierla wrote:
>>>
>>>>
>>>>
>>>> On 08/20/06 17:45, Federico Giannici wrote:
>>>>
>>>>> If a message body is modified by both force_rtp_proxy() and 
>>>>> replace( "^Content-Length:", "l:" ) then the resulting message is 
>>>>> corrupted.
>>>>
>>>>
>>> >
>>>
>>>> if the body of the message is altered, openser rebuilds the content 
>>>> length by removing the old header and adding new one. From here 
>>>> comes the issue.
>>>
>>>
>>>
>>> I don't understand the issue. I cannot see the problem if the header 
>>> field was actually removed and then re-added.
>>>
>>> The problem is that the header field is present in BOTH forms (long 
>>> and compact): "l:Content-Length:".
>>>
>>> Bye.
>>>
>>>
>>>> If you want short header names, the best is to change the sources 
>>>> and update the define at config.h line 70 to compact form of 
>>>> content length header. In the future, maybe only the body of the 
>>>> header should be updated, and this issue will go.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>>
>>>>> The message size is updated but the header field name appear in 
>>>>> both the short and long form. Here it is an example:
>>>>>
>>>>> l:Content-Length: 403
>>>>>
>>>>> The result is the same if I reverse the order of the two 
>>>>> operations too.
>>>>>
>>>>> BTW, I use that replace call (and others) when the message is 
>>>>> large to prevent it to fragment.
>>>>>
>>>>>
>>>>> Bye.
>>>>>
>>>
>>>
>>
>
>