W3C home > Mailing lists > Public > www-lib@w3.org > January to March 1999

Re: Stopping the request in Before filters.

From: olga <olga@goliath.eai.com>
Date: Sun, 17 Jan 1999 17:36:52 -0600 (CST)
Message-ID: <XFMail.990117173652.olga@eai.com>
To: www-lib@w3.org

On 15-Jan-99 Henrik Frystyk Nielsen wrote:
> olga wrote:
>> It there a safer way to stop request in before filters? It would be good if
>> HTNet_newClient after getting the "NOT OK" value from before filters could
>>         1) register some event that would cause the after filters
>>            to be called later
>>         2) RETURN
> I have just committed a small patch to HTNet.c which does this - you can
> find it at
>       http://dev.w3.org/cgi-bin/cvsweb/libwww/Library/src/HTNet.c
> It is also in the list at
>       http://db.w3.org/Library/latest.sql
> This is how you can get it:
>       http://www.w3.org/Library/cvs.html#update
> and do a recompile
>       http://www.w3.org/Library/cvs.html#Easy
> Please check it out to see if it works as indented.
> Henrik


The update seems to work fine. Though sometimes select hangs now... I do not
know if it is result of update (with AfterFilterEvent select is still called
and there are no events on sockets, May be timeval is sometimes NULL in select
call???) or something else happens.

Another problem is with starting request from after filter is that when new
request is started in after filter and access function eventually returns 
- it returns to the HTNetCall_executeAfter of the old request and this function
continues to execute the after filters for the "old request". There are 2

        - old request deleted - then there will be a coredump eventually

        - old request deleted and new created at exactly the same address as
          the old one. (This happens most of the time with my app.) Then 
          after filters of the new request are executed by continuing 
          HTNetCall_executeAfter. This actually terminates the just started

I do not know if it would be safe in the last after filter  of the request to
mark it(request) as TO_BE_DELETED and delete it in HTNetCall_executeAfter when
the access function for the newly started request returns there?

All this sounds like it is not safe to start a new request in an after filter
and this practice should not be used (Is that right?). 


I have not tested fully the change in HTChannl.c (cleaning of FD_Sets after
when channel is deleted).  Though I have seen the same erroneous behavior as
before. (Maybe the problem with after filters somehow interferes(?).

All this takes me so much time and effort :-( ...

Olga Antropova.
Received on Sunday, 17 January 1999 18:33:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:48 UTC