[Serusers] Rewriting URI in the Contact field

[Maxim Sobolev]

On Wed, Jan 15, 2003 at 10:37:42PM +0100, Jiri Kuthan wrote:
> sorry for latency--I'm mostly off-line this week
> 
> At 10:17 PM 1/14/2003, Maxim Sobolev wrote:
> >contact in the message using del_lump/insert_new_lump(), I'm replacing
> >msg->contact->parsed->contacts->uri.s with the pointer to the
> >pkg_malloc'ed buffer passed to the insert_new_lump() and also
> >adjusting [...]->uri.len accordingly. 
> 
> [...]
> 
> Fair enough. I'm not aware of any issues with this smart workaround.
> 
> 
> >> ad reply_route) I fear fix_nated_contact does not help here really.
> >>  From reply_route, you process original requests conserved in share
> >> memory now -- you don't affect replies.
> >
> >Perhaps you are missing something, because my little old buddy gdb
> >disagrees[1] - I am definitely observing "200 OK" reply as msg
> >argument in fix_nated_contact() called from reply_route[].
> 
> My bad -- I did not notice you were using replies in on_positive_reply
> as opposed to using a copy of shmem-ed request in on_negative_reply.
> (Actually, I think that the name 'reply_route' is very confusing and
>  I should change it.)
> 
> I'm not yet sure whether we should go for script programmability for 
> replies. Currently, "as is" it's imho quite unsafe. The script is now 
> built primarily for request processing. Applying some of the 
> request-processing actions to replies might possibly result in 
> unpredictable behaviour. For examples, attempts to manipulate uri's 
> might manipulate other things (union use), or when manipulating lump 
> list,  request lump list (and not reply list) would be mistakenly used.

This is already handled properly by my patches for tm module - before
invoking do_acton() it replaces msg->add_rm with msg->repl_add_rm and
restores it after return from do_action().

> That's just few things which randomly came into my mind -- I'm off-line 
> now and cannot check the code for more details.
> 
> So the options are imho:
> - hard-wire the reply-processing logic in the module.

It's possible, but I don't see how it will differ from my current
approach. In any case, after call-back is invoked the reply will be
passed to adjusting function, the only difference is that in one case
you can control conditions when it happens (i.e. search() match or
something else), while in the other case the logic will be hardcoded
into the module itself.

> - rewriting ser in a way that permits reply processing too (maybe that
>   could be done along with a change to module interface, which would
>   allow to specify what actions make sense for reply processing,
>   on_reply processing and request processing)

Maybe, but I really don't have a time to do it right now. 

-Maxim