[Lispweb] regarding a URL and IMHO (was re: IMHO + mod_lisp)

[Sean Champ]

Hello,

While I was trying to make sure, today, that IMHO would run on my
installation of CMUCL -- and seeming as if it was failing, though I
wasn't sure how --  I encountered the message from Ng Pheng Siong,
at http://www.red-bean.com/pipermail/lispweb/2002-May/000444.html
wherein he stated:

   BTW, mod_webapp doesn't work for me: the first time I connect, the
   Apache child process responsible for my connection segfaults;
   subsequent ones report the error "cannot switch to passive mode".


I was encountering the exact same problem (though I hadn't noticed the
segfault, at first). 

I had narrowed it down to a matter of PARSE-URI, when it finally
became apparent -- and it's quite a punch-line, honestly, after an
afternoon's ineffectual prying at it.



I can try to explain it as follows. Though I'm not altogether sure
if I have the terms right, here it is, anyhow.

When mouting the application 'testapp1' to the webapp mount-point
/testapp1/, the URL http://localhost/testapp1/testapp1 
would be the URL to visit.

... so it's not just http://localhost/testapp1/ as that would not be
enough.


I can try to summarize the cause of it, in what I think I know
of it.


Terminological summary: 

The second 'testapp1' in the URL there, it (might) identify the
application, *within* the mount-point /testapp1/.

(and it could be a 'method' name -- presumably, short for "web
method", though I'm new to some of the terms and concepts embodied of
IMHO)



Technical summary:

In this case, the second 'testapp1'  is required, in order for
PARSE-URI to have any useful side-effects -- like, enough for the
request-response loop/cycle to get beyond the request with type,
"request init uri".



Fortunately, the body of PARSE-URI is documented with such commentary
that did, ultimately, serve to have explained this.


I hope this stands to resolve the matter about mod_webapp and IMHO,
and thank you.



---
Sean Champ
schamp at commonwerx.org