22 Aug
2006
22 Aug
'06
4:24 p.m.
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
yes.
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???
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.
>