Re: [BUG]: "Undying keepalives in 1.2b7" on Solaris 2.x (fwd)

["Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU>]

Ummm, there is a larger problem here.  saferead() assumes that if
there is any input to read, then the client is pipelining and therefore
doesn't want the flush.  Unfortunately, most clients stupidly send
an extra CRLF after a POST request to compensate for that old CERN bug,
which means a POST response won't be flushed before saferead attempts
to read the next nbyte (and blocks).  Worse, it seems that the
between-request timeout is not operating, since that should
cause a close and stop the server child from hanging.

In other words, I haven't stopped looking at the problem yet. :)

.....Roy

>Date: Mon Mar 10 16:30:40 1997
>From: bem@cmc.net
>To: apache-bugs%apache.org@organic.com
>Subject: [BUG]: "Undying keepalives in 1.2b7" on Solaris 2.x
>
>Submitter: bem@cmc.net
>Operating system: Solaris 2.x, version: 
>Version of Apache Used: Apache 1.2b7
>Extra Modules used: mod_log_dir, mod_speling, mod_counter
>URL exhibiting problem: 
>
>Symptoms:
>--
>Multiple processes in 'keepalive' state according to
>/server-status, which terminate only when Apache
>is kill -HUP'd.
>
>It appears that saferead() has some quirks with
>Slugaris 2.5.
>
>--
>
>Backtrace:
>--
>(gdb) where
>#0  0xef67792c in _read ()
>#1  0x35c30 in saferead ()
>#2  0x36118 in bgets ()
>#3  0x2a2e8 in getline ()
>#4  0x2a9fc in read_request_line ()
>#5  0x2b41c in read_request ()
>#6  0x1de78 in child_main ()
>#7  0x1e124 in make_child ()
>#8  0x1ec8c in standalone_main ()
>#9  0x1f038 in main ()

Re: [BUG]: "Undying keepalives in 1.2b7" on Solaris 2.x (fwd)

[Dean Gaudet <dg...@arctic.org>]

I dunno, that's exactly the reason that saferead and B_SAFEREAD were
added.  To eat the extra CRLFs.  If there is input to read, it'll be the
CRLFs so it won't flush, then it'll get back up into read_request_line() 
eat the CRLFs and dive back down for more input.  Eventually it'll
discover nothing more, and the select() will indicate that a read would
block.  Then it'll flush the output before blocking to read from the
client. 

The stack trace would look exactly like the one shown here. 

My money is on a broken request timeout. 

Dean

On Mon, 10 Mar 1997, Roy T. Fielding wrote:

> Ummm, there is a larger problem here.  saferead() assumes that if
> there is any input to read, then the client is pipelining and therefore
> doesn't want the flush.  Unfortunately, most clients stupidly send
> an extra CRLF after a POST request to compensate for that old CERN bug,
> which means a POST response won't be flushed before saferead attempts
> to read the next nbyte (and blocks).  Worse, it seems that the
> between-request timeout is not operating, since that should
> cause a close and stop the server child from hanging.
> 
> In other words, I haven't stopped looking at the problem yet. :)
> 
> .....Roy
> 
> >Date: Mon Mar 10 16:30:40 1997
> >From: bem@cmc.net
> >To: apache-bugs%apache.org@organic.com
> >Subject: [BUG]: "Undying keepalives in 1.2b7" on Solaris 2.x
> >
> >Submitter: bem@cmc.net
> >Operating system: Solaris 2.x, version: 
> >Version of Apache Used: Apache 1.2b7
> >Extra Modules used: mod_log_dir, mod_speling, mod_counter
> >URL exhibiting problem: 
> >
> >Symptoms:
> >--
> >Multiple processes in 'keepalive' state according to
> >/server-status, which terminate only when Apache
> >is kill -HUP'd.
> >
> >It appears that saferead() has some quirks with
> >Slugaris 2.5.
> >
> >--
> >
> >Backtrace:
> >--
> >(gdb) where
> >#0  0xef67792c in _read ()
> >#1  0x35c30 in saferead ()
> >#2  0x36118 in bgets ()
> >#3  0x2a2e8 in getline ()
> >#4  0x2a9fc in read_request_line ()
> >#5  0x2b41c in read_request ()
> >#6  0x1de78 in child_main ()
> >#7  0x1e124 in make_child ()
> >#8  0x1ec8c in standalone_main ()
> >#9  0x1f038 in main ()
>