more problems with filters / endless loop

(using 5.3.2)

sorry that I seem to ask stupid questions, but there is nothing
appropriate in the documentation as to when which filter is called...

so: I need two filters: one for confirmation to overwrite a file, one
for authentication:

        HTAlert_add(doAuthenticate, HT_A_USER_PW);
        HTAlert_add(doConfirm, HT_A_CONFIRM);

further, I found out that I need to have the following
        HTNet_addAfter(doTerminate, 0, 0, HT_ALL, HT_FILTER_LAST);

in which I call a HTEventList_stopLoop(), otherwise the
HTEventList_loop() call never returns.

This works.

Problem1: when I register a per-request-filter:
         HTRequest_addAfter(req, someOther, NULL, NULL, HT_ALL,
HT_FILTER_LAST, TRUE);
(with overwrite == TRUE), then the doAuthenticate and doConfirm filters
are *NOT* called, and the someOther callback is called instead (with
status == -401), but then I would have to re-issue the request with the
authentication information set, which in addition is not cached (as it
is when using the "global" filter, right?) --> doesn't work for me.

When I register this callback using 
         HTRequest_addAfter(req, someOther, NULL, NULL, HT_ALL,
HT_FILTER_LAST, FALSE);

then the doAuthenticate and doConfirm filters are called, but the
doTerminate is *NOT* called, so that I end up in an endless loop
(HTEventList_loop() never returns) --> doesn't work either.

Any hints?

Problem2: I thought that e.g. the redirect-filter (HT_MSG_REDIRECTION)
is called with HT_A_CONFIRM, but this doesn't seem to be the case, ie.
the doConfirm filter (registered with HT_A_CONFIRM) is not called....

Problem3: when I have an ftp request
	ftp://somewhere/something.doc
then the doAuthenticate filter is *NOT* called, and the doTerminate is
called with status == -1

However, when I ask for
	ftp://user@somewhere/something.doc
the doAuthenticate filter *IS* called.

Does that mean that I have to analyze the request URL and see which
protocol is used and whether a user is specified, and if not, first try
it without a user information (because anonymous might work), and if
that fails, re-issue the request with user information, so that my
authentication callback is called and I can provide the password...?
Hmmm.

Any help is GREATLY appreciated!!

TIA,

/oliver

Received on Monday, 20 August 2001 10:22:30 UTC