httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@msoft.com (Jon Teichrow)
Subject Re: r->connection->aborted no longer set?
Date Mon, 27 Jul 1998 17:05:58 GMT
>Yup, this is one of the features of the BSD sockets interface.  You can't
>find out a client has gone away until you write something to it.  One way
>to work around it is to send a space and rflush() every few seconds... it
>sucks.
>
>Dean


I ran into this problem a while back (see below, if interested) and if you
send a space via ap_rputs you may have a bogus client which will, under
Windows, cause a GPF when accessed.  As a workaround, I used an exception
handler to catch the resulting GPF and manually set the aborted flag.  This
still did not do the trick - another GPF occured outside my module because
of the bogus client.

-- Related Info --

>I tried the obvious with no luck.  Here's my code:
>
>// Output data in printf fashion
>int COutputManager::printf(const char *fmt, ...) const
>{
>    int n=0;
>    va_list vlist;
>
>    va_start(vlist, fmt);
>    if (!m_r->connection->aborted)
>        n = ap_vbprintf(m_r->connection->client, fmt, vlist);
>    va_end(vlist);
>
>    return n;
>}
>
>Basically, "aborted" is never set and, so, the call goes through to
>ap_vbprintf with a bogus "client".  I don't think using ap_rputs will help
>because it will begin using client in the same way.  If it helps, my
>handler is not furiously calling my printf function.  In fact, at the time
I
>hit the "Stop" button in the client, I am trying to connect to Oracle via
>OCI.  The connection attempt to Oracle is never halted.  Upon return
>from connecting to Oracle the module then starts ouputting via printf,
>but the connection at that point is bogus.  I'll dig deeper...
>
>Many thanks,
>
>Jon
>
>-----Original Message-----
>From: Dean Gaudet <dgaudet@arctic.org>
>To: new-httpd@apache.org <new-httpd@apache.org>
>Date: Thursday, June 11, 1998 2:07 PM
>Subject: Re: Win32 module problem
>
>>Use the ap_r*() functiosn such as ap_rputs().  If you don't, then you have
>>to properly test r->connection->client->aborted ... or something like
>>that.  Go look at ap_rputs() et al for an example.
>>
>>Dean
>>
>>On Thu, 11 Jun 1998, Jon Teichrow wrote:
>>
>>> Greetings,
>>>
>>> Having a bit of trouble with a module I'm writing.
>>> My current development environment is Win32 hosted
>>> (1.3b7).
>>>
>>> During the handling of a request that is aborted
>>> from the client (e.g. user hits *Stop* in browser) my
>>> module is never given an indication that the connection
>>> was terminated.  Not knowing of the termination,
>>> my module continues to output HTML and eventually
>>> croaks because "r->connection->client" is bogus.  I have
>>> registered cleanup functions but these are not called.  Am
>>> I not providing a hook I should be?
>>>
>>> Thanks.
>>>


Mime
View raw message