If a message body is modified by both force_rtp_proxy() and replace( "^Content-Length:", "l:" ) then the resulting message is corrupted.
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.
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.
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.
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.
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.....
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.
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???
I think this is a GREAT limitation (I'd call it a bug) of the lumps handling code...
Bye.
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.
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.
Bogdan-Andrei Iancu wrote:
Federico Giannici wrote:
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.....
I remain convinced that, if parallel modifications of different HFs is possible (so there must be a mechanism to update pointers to others HFs), then two modifications of the same HF should be possible too.
Unfortunately, I'm not a good enough C programmer to do it... ;-)
Bye.
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Federico Giannici