15 Jan
2003
15 Jan
'03
11:37 p.m.
sorry for latency--I'm mostly off-line this week
At 10:17 PM 1/14/2003, Maxim Sobolev wrote:
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.
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.
- 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)
-Jiri
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[].