[AOLSERVER] ns_unregister_filter

[Ian Harding]

I know there's no such thing, but is there any way to add/delete
filters willy-nilly while the server is running?

Thanks,

- Ian

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.

[Tom Jackson]

No, there are code comments which suggest that you can add a filter and then
delete it before virtual servers are initialized (while there is one thread),
but all trie structures are read/write no delete after startup. Anything
having to do with url pattern matching is in this category.

tom jackson

On Thursday 29 November 2007 08:10, Ian Harding wrote:
> I know there's no such thing, but is there any way to add/delete
> filters willy-nilly while the server is running?

[Rick Cobb]

While we're on the subject of the trie data structures, has there been
any attempt to support component-level pattern matching in these?

E.g., in a RESTful application, it's often useful to do something like
(making up a Tcl syntax based on the URI-template W3C proposal as I go):

ns_register_proc -noinherit PUT {/who/{user}/login/{session}} my_proc
$user $session

In this case, I'd want any PUT to any URL that matched (regex now)

{^/who/([^/]+)/login/([^/]+}[/]{0,1}$}

to call my_proc -- and I'd like it to give me those two matched
substrings as arguments.

We can do these things with ns_register_filter, but it means we do a lot
of string matching in Tcl or our own C/C++ routines rather than in the
tries.

-- ReC

[Ian Harding]

Great. Thanks!

[Tom Jackson]

The main thing to keep in mind is that the trie code is mostly undocumented.
There is some old documentation here:

http://rmadilo.com/files/docs/devel/tech/urlspace.html

My guess is that the best way to address this is to use an internal redirect.

The first match would be on PUT and maybe /who/.

This filter, which could be written in C, can modify the url. Then the next
filter matching will use the new url.

From what I remember, matching is just a cycling through the list of filters
so that the first one registered is tested first.

Anyway, the first filter could actually trim down the url and set some
variables:

/who/me/session/abc/something_else

becomes

/handle_something_else

If the path+file handle_something_else exists under pageroot, then you are
done! Or, you can register a proc to handle that specific url.

If you need more categories after the first, you just insert another filter
which matches something below /handle_something_else.

So, to summarize, component-level pattern matching where you do everything in
one shot, would be difficult to manage. You register filters to handle some
number of components, then you use another filter to specialize if necessary.
Eventually you can just use a registered_proc. (since it is put, you can't
just let it fall through to fastpath).

tom jackson