[plt-scheme] Re: url rewriting
> A little while back, I had gotten through reading about half of the
> implementation code for the 352 version of the web server. i remember
> reading about how it runs a sequence of dispatchers for logging,
> authentication, running the servlet, etc.
>
> This seems similar to Apache's 18 or 19 (fixed) call out points in the
> process of handling a request. i believe most programs using a mod_*
> language only make use of the plug in point for producing the http
> response.
Apache's 18 or 19 call out points is the moral equivalent of a
language with 3 looping constructs. The web-server is foremost the PLT
Scheme web server, and thereby allows the user unlimited flexibility.
They can complete customize the arrangement, number, etc of the
dispatching request handlers.
> anyways, just curious to hear any thoughts you have on Unlib's
> pipelines (where each stage/function in the pipeline is given the
> continuation that it may or may not choose to call) versus this
> dispatcher architecture.
>
> i'm wondering if exposing a pipeline interface out of the server would
> provide even more power to the developer? i'm guessing the dispatchers
> run in sequence every time, possibly with the option to signal a fatal
> error to stop the rest of the sequence from running.
I would have to understand more why they are using the pipelines.
There is definitely something which would make life easier for the
developers. Currently it is difficult to have something happen to
EVERY incoming request and EVERY outgoing response to a servlet, being
specified within the servlet. This would be useful for making SXML
output or easier checking of cookie/auth credentials. I'm thinking
about how best to do this.
> Jay,
>
> another minor unrelated note, from developing with the 352 web
> server(which as always i love), one especially annoying behavior is if
> you accidentally provide malformed sxml, when invoking the servlet, it
> runs endlessly instead of reporting an error to the client. another is
> wondering where the errors from misbehaving servlet are logged if
> anywhere (I haven't done much digging to see if its in an obvious
> place)
I am working on that 'forever' error. Servlet errors are printed to
the console. You'll have to log the terminal for now.
> also...on your continuation advice from before, i haven't tried it yet,
> but will soon. i'm still hand rolling my scheme and javascript
> continuation points. leaning towards macros like:
> (def-scheme function-name arguments environment body)
> (def-js function-name arguments environment body)
> which generate the definitions with the (lambda (env) (lambda (args)
> ... )) as well as stub functions for calling from scheme to javascript
> or vice versa. automates some grunt work, without taking too much
> control away from the developer..also haven't had time to really read
> the continuation mark based algorithm yet.
This seems like dangerous ground. I'd think very hard about what you
want before you do it.
Jay
>
> kanishka
>
> >>
> From: Jay McCarthy <jay.mccarthy at ...>
> Subject: Re: url rewriting
> Newsgroups: gmane.lisp.scheme.plt
> Date: 2007-06-07 23:53:07 GMT (4 hours and 40 minutes ago)
>
> Yes, it is possible.
>
> Implement a custom dispatcher [1] that does the rewriting, then use
> your own dispatching sequencing and put the rewriting dispatcher at
> the start. Everything "will just work". Send me the code and I can
> then integrate it. Basically you want:
>
> ; make : (url? -> url?) (conn? req? -> void) -> (conn? req? -> void)
> (define (make url->url inner)
> (lambda (conn req)
> (inner conn (update-request-url req (url->url (request-url req))))))
>
> Jay
>
> 1. See new documentation, in SVN after `mzscheme -mvt
> docs/doc-installer.ss' or online at:
>
> http://jay.teammccarthy.org/tmp/web-server-reference/dispatchers.html#(part%20dispatchers)
> >>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
--
Jay McCarthy <jay.mccarthy at gmail.com>
http://jay.teammccarthy.org