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