Project

General

Profile

Actions

Feature #961

closed

mod_lisp

Added by agrostis over 17 years ago. Updated over 7 years ago.

Status:
Invalid
Priority:
Normal
Category:
3rd party
Target version:
-
ASK QUESTIONS IN Forums:

Description

A module which (I hope) might add some virtue to the distribution. It is a port of Marc Battyani's mod_lisp, realizing exactly the same httpd<->lisp protocol.

The C source is attached herewith; I have been able to compile it with lighttpd 1.4.13 on Darwin/PPC as well as FreeBSD/x86. The source of the problem which I have described in #627 has been eliminated, thus, no changes to base.h are needed for mod_lisp to run properly. (On the other hand, re-running Autoconf—2.59 and_ 2.61, on both above platforms—met with utter failure for the .in files provided in the distribution.)

I would very much appreciate your review and criticism of the code.

----
And here is one formal issue: when writing the code, I, of course, relied heavily on the Battyani sources, so that it seemed proper to me to retain his copyright conditions. However, Battyani, in his turn, drew inspiration from Apache's mod_skeleton, and so has kept the Apache copyright. There is practically no Apache code left in my mod_lisp (the LOGLEVEL system is the only exception I can think of), so we might want to think how to get rid of the Apache copyright, all the more so because it stipulates that derived products have to mention Apache in their advertising materials (clause 3).


Files

mod_lisp.c (39.1 KB) mod_lisp.c agrostis, 2007-01-04 03:58
Actions #1

Updated by agrostis almost 16 years ago

I have set up a darcs repository at http://dpworks.net/darcs/mod_lisp-lighttpd/ that includes the most recent source for mod_lisp.c, patches for makefiles of various versions of lighttpd (1.4.x), as well as much-asked-for installation instructions (mod_lisp has not been officially included in the distribution and has to be sneaked in by willing users, which is not at all trivial).

Actions #2

Updated by gstrauss almost 8 years ago

  • Description updated (diff)
  • Category changed from core to 3rd party
  • Assignee deleted (jan)
Actions #3

Updated by gstrauss over 7 years ago

  • Status changed from New to Invalid

The supplied module is largely a fork of what was then mod_proxy, with slight modifications to the format of the strings sent to the lisp server and how the response is parsed. Major work would be needed on mod_lisp to remove blocking and add support for streaming of request/response -- probably a new fork of mod_proxy or mod_scgi, with the subsequent changes needed for the string formats assumed by backend lisp server. It would be much more advisable for the backend lisp server to speak the HTTP protocol (or the SCGI protocol) instead of duplicating a whole lot of code from mod_proxy in order to slightly, but incompatibly, change the string format assumed by the backend lisp server.

Another option: Recently, slight modification was made to mod_scgi to support the uwsgi protocol (a661944d) and potential similar changes could be made to support the format used by this mod_lisp, without having to duplicate a whole lot of code into a new module (mod_lisp).

Given the brief code I found at http://www.fractalconcept.com/fcweb/download/mod-lisp.lisp, it does not look that difficult to change the response header format to be the same as that expected from the likes of mod_proxy, mod_cgi, mod_fastcgi, and mod_scgi. The lisp should add a ':' between response header key and value, instead of a newline, and the lisp should skip writing "end" at the end of the response headers, leaving just a blank line to indicate end of response headers. Small changes should likewise be made to the few lines of lisp that read the request headers so that it can simply parse an HTTP request header, rather than requiring a special format.

tl;dr: withdrawing this feature request as "Invalid". There is no need for a separate module mod_lisp, when the sample backend code given at fractalconcept.com can be relatively easily modified to parse a standard HTTP request header and produce a standard HTTP response header. Then, lighttpd can use mod_proxy to connect to the backend lisp application server, with no changes needed by lighttpd to support this.

FYI: updated links:
http://dpworks.net/miscellanea/mod_lisp-lighttpd.html
https://github.com/agrostis/mod_lisp-lighttpd

Actions #4

Updated by gstrauss over 7 years ago

From https://github.com/agrostis/mod_lisp-lighttpd/blob/master/mod_lisp.README

mod_lisp-lighttpd has been phased out and is no longer actively
maintained.  The advisable way to expose your Lisp applications to
Lighttpd is by using a modern Web server Lisp-side (as of the time
of this writing, Sept. 2015, the available options include at least
Woo, TPD2 and Hunchentoot) and mod_proxy Lighty-side.

Actions

Also available in: Atom