Rearranging the quotes, since I think you actually replied to
my #1 question with your #2 answer, and vice-versa...
Edi Weitz <firstname.lastname@example.org> wrote:
| email@example.com (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
Anyway, thanks for your answers (even if they weren't entirely
what I had hoped to hear)...
Rob Warnock, PP-ASEL-IA <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607