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.
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
