You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Morgan <im...@webcon.net> on 2002/01/26 20:50:22 UTC

[PATCH] RecvTimeout directive for 1.3.23

>From the 1.3.23 ChangeLog:

> (eg, one attack mode of the Nimda worm is to establish a connection to the
> server but not send an HTTP request. This connection will be timed out
> according to the setting of the Timeout directive, 300 seconds)

Well, they seem to recognize the problem, anyways. Anybody know why this
patch isn't being accepted? It works like a charm.

My patch to add a RecvTimeout directive to Apache has been ported up to
1.3.23.

Details:
http://www.webcon.net/opensource/apache/

Download:
http://www.webcon.net/opensource/apache/apache_1.3.23_recv_timeout.patch


Regards,
Ian Morgan
-- 
-------------------------------------------------------------------
 Ian E. Morgan        Vice President & C.O.O.         Webcon, Inc.
 imorgan@webcon.net         PGP: #2DA40D07          www.webcon.net
-------------------------------------------------------------------


[PATCH] RecvTimeout directive for 1.3.23 (v2)

Posted by Ian Morgan <im...@webcon.net>.
On Sat, 26 Jan 2002, William A. Rowe, Jr. wrote:

> From: "Jeff Trawick" <tr...@attglobal.net>
> Sent: Saturday, January 26, 2002 2:29 PM
>
> > IIRC, it added to the server_rec which would require an API MMN bump,
> > and I think somebody mentioned that on the list.
>
> Yes - this is true.  But if the field is added to the end of the structure,
> this requires a Minor bump, and that was deemed suitable for 1.3.23's change
> with the INodeEtag change.  Food for thought.
>

Aha.. ok, well here is the patch updated with the server_rec changes moved
to the end of the structure.. perhaps the team might like it now?

http://www.webcon.net/opensource/apache/apache_1.3.23_recv_timeout_v2.patch

Regards,
Ian Morgan
-- 
-------------------------------------------------------------------
 Ian E. Morgan        Vice President & C.O.O.         Webcon, Inc.
 imorgan@webcon.net         PGP: #2DA40D07          www.webcon.net
-------------------------------------------------------------------


Re: [PATCH] RecvTimeout directive for 1.3.23

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Jeff Trawick" <tr...@attglobal.net>
Sent: Saturday, January 26, 2002 2:29 PM


> Ian Morgan <im...@webcon.net> writes:
> 
> > >From the 1.3.23 ChangeLog:
> > 
> > > (eg, one attack mode of the Nimda worm is to establish a connection to the
> > > server but not send an HTTP request. This connection will be timed out
> > > according to the setting of the Timeout directive, 300 seconds)
> > 
> > Well, they seem to recognize the problem, anyways. Anybody know why this
> > patch isn't being accepted? It works like a charm.
> 
> IIRC, it added to the server_rec which would require an API MMN bump,
> and I think somebody mentioned that on the list.

Yes - this is true.  But if the field is added to the end of the structure,
this requires a Minor bump, and that was deemed suitable for 1.3.23's change
with the INodeEtag change.  Food for thought.

Bill


Re: [PATCH] RecvTimeout directive for 1.3.23

Posted by Ian Morgan <im...@webcon.net>.
On 26 Jan 2002, Jeff Trawick wrote:

> Ian Morgan <im...@webcon.net> writes:
>
> > >From the 1.3.23 ChangeLog:
> >
> > > (eg, one attack mode of the Nimda worm is to establish a connection to the
> > > server but not send an HTTP request. This connection will be timed out
> > > according to the setting of the Timeout directive, 300 seconds)
> >
> > Well, they seem to recognize the problem, anyways. Anybody know why this
> > patch isn't being accepted? It works like a charm.
>
> IIRC, it added to the server_rec which would require an API MMN bump,
> and I think somebody mentioned that on the list.

Ah, that's reasonable I suppose. I had not seen any such comment on the
list, but I suppose I may have misesd it.

Anybody have any ideas on how to implement this without touching server_rec?
(Who uses binary modules across versions without recompiling!?)


> > Download:
> > http://www.webcon.net/opensource/apache/apache_1.3.23_recv_timeout.patch
>
> --> BAD URL

Oops.. Sorry. Mixed up a "-" and an "_". It's accessible now.

> Is this in 2.0 yet?

Don't think so. There seems to be some form of support for a variety of
different timeouts is 2.0.x, but when I last looked, I don't think there was
one that handles this type of timeout for receives only. Of course, I'd be
happy to stand corrected.

Regards,
Ian Morgan
-- 
-------------------------------------------------------------------
 Ian E. Morgan        Vice President & C.O.O.         Webcon, Inc.
 imorgan@webcon.net         PGP: #2DA40D07          www.webcon.net
-------------------------------------------------------------------


Re: [PATCH] RecvTimeout directive for 1.3.23

Posted by Jeff Trawick <tr...@attglobal.net>.
Ian Morgan <im...@webcon.net> writes:

> >From the 1.3.23 ChangeLog:
> 
> > (eg, one attack mode of the Nimda worm is to establish a connection to the
> > server but not send an HTTP request. This connection will be timed out
> > according to the setting of the Timeout directive, 300 seconds)
> 
> Well, they seem to recognize the problem, anyways. Anybody know why this
> patch isn't being accepted? It works like a charm.

IIRC, it added to the server_rec which would require an API MMN bump,
and I think somebody mentioned that on the list.

Maybe you addressed that, maybe I'm extremely confused, maybe both.  I
tried to verify but (see next comment)

> Download:
> http://www.webcon.net/opensource/apache/apache_1.3.23_recv_timeout.patch

--->bad URL

bad URL on the page mentioned previously too

Is this in 2.0 yet?  I think that lots of people think it is cool and
appropriate for Apache.  The question (IIRC) is which release.  I
don't think there is any question that an appropriate patch for 2.0
would have an easy time.

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...