Subject: Re: mod_lisp 2.3 beta available for testing
From: rpw3@rpw3.org (Rob Warnock)
Date: Wed, 08 Jan 2003 04:25:45 -0600
Newsgroups: comp.lang.lisp
Message-ID: <zySdnTq3_OE0YYajXTWc3Q@giganews.com>
Rearranging the quotes, since I think you actually replied to
my #1 question with your #2 answer, and vice-versa...

Edi Weitz <edi@agharta.de> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > 1. Does this in any way affect the ability (very important in
| >    some applications!) to "stream" data through Apache to the
| >    client browser, so that the beginning of the output gets to
| >    the browser early to give the user something to look at while
| >    the rest is being computed (e.g., with a slow database access)?
|
| 2. mod_lisp requires the Lisp image to provide a correct
|    "Content-length" header _before_ sending the body, i.e. in almost
|    all cases you won't be able to send data to the client before you
|    have finished computing your dynamic page.
+---------------

Gee, that's too bad. The ability to "stream" data (HTML, at least)
to the client without knowing in advance how long it is it quite
useful in many situations.

Does "mod_lisp" at least let you use HTTP/1.1 "chunked" transfer
encoding to achieve such incremental output? And can you do that
even if it's an HTTP/1.0 client?

+---------------
| > 2. What are the implications for a "runaway" Lisp process that
| >    generates infinite output? Normally when that happens and
| >    the user (say) manually hits "Stop" (aborting the connection),
| >    the abort would propagate back to the Lisp process as a
| >    SIGPIPE (which could be caught & handled), would it not?

| I think both of these concerns don't apply to the way mod_lisp works.
| 1. mod_lisp communicates with the Lisp image through a socket
|    connection. This is _not_ the connection between Apache and the
|    browser (and thus an aborted http connection won't propagate
|    through to the Lisp image as a SIGPIPE).
+---------------

Well, that's up to "mod_lisp" to decide, which is why I asked.
Certainly one could design an API that *did* pass the abort
through -- it's one of the available design decisions. And if
you support "chunked" transfer encoding (see other question),
then there are some cases where you'd *want* to pass it through,
to avoid wasting lots of expensive resources computing massive
amounts of data that "mod_lisp" would just throw on the floor
(after a client abort). [E.g., a suitably-malicious client could
launch a DoS attack against a "mod_lisp"-based server by making
*large* numbers of "expensive" requests and then immediately
aborting them.]

Anyway, thanks for your answers (even if they weren't entirely
what I had hoped to hear)...


-Rob

-----
Rob Warnock, PP-ASEL-IA		<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607