You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 2000/02/02 22:38:14 UTC
Re: Bug Report 5671 - CGI Deadlock
>2) Is it 'legal' to be transmitting the http result to the client, while the
>client isn't done transmitting the request?
Yes, you just need to be careful not to close the connection before
the recipient has a chance to ack the response packet and that ack
is received by the server (hence, lingering close).
....Roy
Re: Bug Report 5671 - CGI Deadlock
Posted by Tony Finch <do...@dotat.at>.
Dean Gaudet <dg...@arctic.org> wrote:
>
>it's ironic this topic is coming up right now... i just got my hands on
>the early bind9 code and they've got a really nice async i/o abstraction
>in it which could be used to build a really nice proxy. the pieces are
>coming together :)
Is it different from Bind8's eventlib? I've written a simple
concurrent HTTP client using that, and it's quite nice, especially
compared to the internals of Squid.
Tony.
--
** **
*** *** *** **** *** ******* *** *** **** *** ****
*** *** * *** *** *** * ***
HTTP Router/Proxy (was Re: Bug Report 5671 - CGI Deadlock)
Posted by Sander van Zoest <sa...@mp3.com>.
On Sat, 5 Feb 2000, Jeffrey W. Baker wrote:
> Dean Gaudet wrote:
> > 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.
> > to do this stuff properly really requires poll/select and careful state
> > machine programming.
> > it's ironic this topic is coming up right now... i just got my hands on
> > the early bind9 code and they've got a really nice async i/o abstraction
> > in it which could be used to build a really nice proxy. the pieces are
> > coming together :)
> Hrmm, I'm really interested in this. The reason I started poking around
> with Apache 2.0 is that I am writing a buffering HTTP proxy to allow a
> higher request rate between Apache 1.3 servers and clients on
> connections of varying speeds. Clearly I would rather leverage solid
> open source code than maintain my own. I remember hearing that async
> i/o isn't going to make it into 2.0, but if a third party (bind) comes
> up with something nice that can be generalized for Apache, that would be
> a huge leap forward for HTTP server technology.
We have had similar plans to write a slim http-router/proxy type server to
handle low-bandwidth clients without tie-ing up the larger dynamic server.
If we can add in async i/o and have this be an open source tools/project
the better for everyone.
-
Sander van Zoest sander@mp3.com
High Geek (858) 623-7442
MP3.com, Inc. http://www.mp3.com/
Your premiere Music Service Provider (MSP)
Re: Bug Report 5671 - CGI Deadlock
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
Dean Gaudet wrote:
>
> 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.
>
> to do this stuff properly really requires poll/select and careful state
> machine programming.
>
> it's ironic this topic is coming up right now... i just got my hands on
> the early bind9 code and they've got a really nice async i/o abstraction
> in it which could be used to build a really nice proxy. the pieces are
> coming together :)
Hrmm, I'm really interested in this. The reason I started poking around
with Apache 2.0 is that I am writing a buffering HTTP proxy to allow a
higher request rate between Apache 1.3 servers and clients on
connections of varying speeds. Clearly I would rather leverage solid
open source code than maintain my own. I remember hearing that async
i/o isn't going to make it into 2.0, but if a third party (bind) comes
up with something nice that can be generalized for Apache, that would be
a huge leap forward for HTTP server technology.
-jwb
RE: Bug Report 5671 - CGI Deadlock
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
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.
Re: Bug Report 5671 - CGI Deadlock
Posted by Dean Gaudet <dg...@arctic.org>.
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.
to do this stuff properly really requires poll/select and careful state
machine programming.
it's ironic this topic is coming up right now... i just got my hands on
the early bind9 code and they've got a really nice async i/o abstraction
in it which could be used to build a really nice proxy. the pieces are
coming together :)
Dean
On Sat, 5 Feb 2000, Mike Gray wrote:
> I am very curious what limitations a proxy server would have on this design.
> For example, if you have a proxy server sitting between the desktop browser
> software and the web server where your cgi is installed. Will it let all of
> this traffic through? Do most proxy servers allow full-duplex transmission?
> (obviously an SSL capable proxy would have to in order for the handshake to
> occur, right?)
>
> mikeg
>
> "William A. Rowe, Jr." wrote:
>
> > Precisely, Dean.
> >
> > I'm looking at hacking a full-duplex cgi (targeting 2.0, not 1.3.x!!!)
> >
> > My metacode idea is;
> >
> > while (get inbuf <- client) {
> > write inbuf -> cgi stdinpipe
> > while (!empty cgi stdoutpipe)
> > read outbuf <- cgi stdoutpipe
> > put outbuf -> client
> > }
> > while (!empty cgi stdoutpipe)
> > read outbuf <- cgi stdoutpipe
> > put outbuf -> client
> > }
> > close client connections
> >
> > The problem I have is with the size of the pipes. NT's are VERY small by
> > default. I discovered this with a simple CGI writing the client stream back
> > at the client as a hexdump.
> >
> > Limited application? Perhaps... but it would appear to the browser as a
> > more async processes flow. Thresholds would be required... delta time or
> > size, but I'll think that through if this proves worthwhile.
> >
> > Additional thoughts anyone?
> >
> > Bill
>
>
Re: Bug Report 5671 - CGI Deadlock
Posted by Mike Gray <mi...@avantgo.com>.
I am very curious what limitations a proxy server would have on this design.
For example, if you have a proxy server sitting between the desktop browser
software and the web server where your cgi is installed. Will it let all of
this traffic through? Do most proxy servers allow full-duplex transmission?
(obviously an SSL capable proxy would have to in order for the handshake to
occur, right?)
mikeg
"William A. Rowe, Jr." wrote:
> Precisely, Dean.
>
> I'm looking at hacking a full-duplex cgi (targeting 2.0, not 1.3.x!!!)
>
> My metacode idea is;
>
> while (get inbuf <- client) {
> write inbuf -> cgi stdinpipe
> while (!empty cgi stdoutpipe)
> read outbuf <- cgi stdoutpipe
> put outbuf -> client
> }
> while (!empty cgi stdoutpipe)
> read outbuf <- cgi stdoutpipe
> put outbuf -> client
> }
> close client connections
>
> The problem I have is with the size of the pipes. NT's are VERY small by
> default. I discovered this with a simple CGI writing the client stream back
> at the client as a hexdump.
>
> Limited application? Perhaps... but it would appear to the browser as a
> more async processes flow. Thresholds would be required... delta time or
> size, but I'll think that through if this proves worthwhile.
>
> Additional thoughts anyone?
>
> Bill
RE: Bug Report 5671 - CGI Deadlock
Posted by Dean Gaudet <dg...@arctic.org>.
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. short term, you should probably do whatever works for
yourself. it's your call.
this does tie into another topic here recently -- the "http router"
concept. in that case the router would ideally have an asynchronous i/o
engine and you'd just hand it the fds and let it do the bit shuffling.
Dean
On Sat, 5 Feb 2000, William A. Rowe, Jr. wrote:
> Precisely, Dean.
>
> I'm looking at hacking a full-duplex cgi (targeting 2.0, not 1.3.x!!!)
>
> My metacode idea is;
>
> while (get inbuf <- client) {
> write inbuf -> cgi stdinpipe
> while (!empty cgi stdoutpipe)
> read outbuf <- cgi stdoutpipe
> put outbuf -> client
> }
> while (!empty cgi stdoutpipe)
> read outbuf <- cgi stdoutpipe
> put outbuf -> client
> }
> close client connections
>
> The problem I have is with the size of the pipes. NT's are VERY small by
> default. I discovered this with a simple CGI writing the client stream back
> at the client as a hexdump.
>
> Limited application? Perhaps... but it would appear to the browser as a
> more async processes flow. Thresholds would be required... delta time or
> size, but I'll think that through if this proves worthwhile.
>
> Additional thoughts anyone?
>
> Bill
>
> > > --- is it 'legal' to BEGIN transmitting the http result
> > > while the client is still trasmitting their request? (Yes - I
> > > know that sounds odd, but I need to determine if the workaround is
> > > immediate transmit of response data - or some alternate queuing
> > > method to ensure the two streams don't deadlock).
> >
> > from an http point of view it's legal. but i think you're
> > asking from the
> > point of view of a cgi ... and mod_cgi just doesn't support
> > full-duplex
> > operation.
> >
> > Dean
> >
>
>
RE: Bug Report 5671 - CGI Deadlock
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Precisely, Dean.
I'm looking at hacking a full-duplex cgi (targeting 2.0, not 1.3.x!!!)
My metacode idea is;
while (get inbuf <- client) {
write inbuf -> cgi stdinpipe
while (!empty cgi stdoutpipe)
read outbuf <- cgi stdoutpipe
put outbuf -> client
}
while (!empty cgi stdoutpipe)
read outbuf <- cgi stdoutpipe
put outbuf -> client
}
close client connections
The problem I have is with the size of the pipes. NT's are VERY small by
default. I discovered this with a simple CGI writing the client stream back
at the client as a hexdump.
Limited application? Perhaps... but it would appear to the browser as a
more async processes flow. Thresholds would be required... delta time or
size, but I'll think that through if this proves worthwhile.
Additional thoughts anyone?
Bill
> > --- is it 'legal' to BEGIN transmitting the http result
> > while the client is still trasmitting their request? (Yes - I
> > know that sounds odd, but I need to determine if the workaround is
> > immediate transmit of response data - or some alternate queuing
> > method to ensure the two streams don't deadlock).
>
> from an http point of view it's legal. but i think you're
> asking from the
> point of view of a cgi ... and mod_cgi just doesn't support
> full-duplex
> operation.
>
> Dean
>
RE: Bug Report 5671 - CGI Deadlock
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 2 Feb 2000, William A. Rowe, Jr. wrote:
> > >2) Is it 'legal' to be transmitting the http result to the
> > > client, while the client isn't done transmitting the request?
> >
> > Yes, you just need to be careful not to close the connection before
> > the recipient has a chance to ack the response packet and that ack
> > is received by the server (hence, lingering close).
> >
> > ....Roy
>
> Let me rephrase - is it 'legal' to BEGIN transmitting the http result
> while the client is still trasmitting their request? (Yes - I
> know that sounds odd, but I need to determine if the workaround is
> immediate transmit of response data - or some alternate queuing
> method to ensure the two streams don't deadlock).
from an http point of view it's legal. but i think you're asking from the
point of view of a cgi ... and mod_cgi just doesn't support full-duplex
operation.
Dean
RE: Bug Report 5671 - CGI Deadlock
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> >2) Is it 'legal' to be transmitting the http result to the
> > client, while the client isn't done transmitting the request?
>
> Yes, you just need to be careful not to close the connection before
> the recipient has a chance to ack the response packet and that ack
> is received by the server (hence, lingering close).
>
> ....Roy
Let me rephrase - is it 'legal' to BEGIN transmitting the http result
while the client is still trasmitting their request? (Yes - I
know that sounds odd, but I need to determine if the workaround is
immediate transmit of response data - or some alternate queuing
method to ensure the two streams don't deadlock).
Thx,
Bill