httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: Bug Report 5671 - CGI Deadlock
Date Sun, 06 Feb 2000 00:36:38 GMT
Thanks, all, for the comments...

> i'm pretty sure squid is full duplex... but i doubt mod_proxy
> is.  even SSL doesn't require full-duplex, it just has a few
> back-and-forths which fit inside most reasonably sized buffers.

My concern is large (> 8KB or 64KB) POST submissions, which
upon a long reply (perhaps simply 8KB on the NT platform)
deadlock the read pipes.  Since these are file uploads, I
can't picture a situation where they would even be cached.

See the original attached C code example from which I noticed the issue.  It
simply dumps the arguments, environment and stdin stream.

It fails with simply 8KB in the pipes (not hard to hit, since 2KB expands
over fourfold when hex dumped).  I am very interested if any Unix folk can
determine an approx. threashold where the CGI fails on their platform.  I
have been able to lock up the process under linux, seems closer to 64KB
there.  If the general threshold is 64KB, I will propose a patch to match
that under NT, just for now.

I'm working up a safe (escaped to prevent SSI attack) version just for kicks
(and will include a mainframe style text over 2 hex rows format).

> to do this stuff properly really requires poll/select and
> careful state machine programming.

> in 2.0 a portable way to do this would be to spawn two
> threads... but that opens a whole can of worms :)
> (the portability vs. efficiency debate)

> i think this is a limited application -- you're probably the
> first to need full duplex cgi.

I like 2 threads (3 threads? let's not forget stderr).  But it probably is
not the single correct solution.  I came up with several options, but want
to see what 'fits' into the 2.0 schema.

View raw message