Seems like a common use case would be to run a server where a few webapps handle certain routes, then any unhandled request get routed to a static file server mod. Like:
pipeline := PipelineMod
{ steps =
[ RouteMod
{ routes =
[ // various apps...
]
},
FileMod { file = pubDir } // serve static files from pubDir root
]
// steps to run after every request
after = [ LogMod { file = logDir + `web.log` } ]
... basically the Fantom example, plus a default handler. Couple problems with that:
First, FileMod breaks when it gets a / request; it tries to load from my harddisk root. I changed its onRequest handler like this:
// get file under directory
f := this.file.plus(req.modRel.relTo(`/`), false)
(adding the relTo(`/`) ) and got past that. But that might break something else, dunno.
Next thing is that then, PipelineMod tries to route request that have already been handled to that pubDir FileMod handler, and throws WebRes already committed error. Apparently PipelineMod is checking res.done to see if it should continue, but FileMod isn't setting the flag.
So, is this just breakage from recent changes, or am I doing something wrong?
brianThu 11 Feb 2010
There is (by design) no mod that chains thru to figure out dispatch or with a fall-thru case. We designed it such that a given WebMod should always own a specific piece of the URI space. Of course that is just a philosphy we used to design the API, certainly it would be pretty trivial to create your top level WebMod that did what you want.
Pipeline is designed to do pre/post processing - you shouldn't have multiple steps trying to actually write the response. Likewise the done flag is more for error conditions, such as redirect where you want to skip something like a logging step.
Best practice is to design your functionality as reusable WebMods that use modBase and modRel without assumptions of their top level URI. Then glue everything together with a top level Mod (typically in just a boot script) and typically we just make "/" and "favicon.ico" a special case there.
KevinKelleyThu 11 Feb 2010
Thanks, figured I must be going against the grain somehow.
KevinKelley Thu 11 Feb 2010
Seems like a common use case would be to run a server where a few webapps handle certain routes, then any unhandled request get routed to a static file server mod. Like:
... basically the Fantom example, plus a default handler. Couple problems with that:
First, FileMod breaks when it gets a / request; it tries to load from my harddisk root. I changed its
onRequest
handler like this:(adding the
relTo(`/`)
) and got past that. But that might break something else, dunno.Next thing is that then, PipelineMod tries to route request that have already been handled to that pubDir FileMod handler, and throws
WebRes already committed
error. Apparently PipelineMod is checkingres.done
to see if it should continue, but FileMod isn't setting the flag.So, is this just breakage from recent changes, or am I doing something wrong?
brian Thu 11 Feb 2010
There is (by design) no mod that chains thru to figure out dispatch or with a fall-thru case. We designed it such that a given WebMod should always own a specific piece of the URI space. Of course that is just a philosphy we used to design the API, certainly it would be pretty trivial to create your top level WebMod that did what you want.
Pipeline is designed to do pre/post processing - you shouldn't have multiple steps trying to actually write the response. Likewise the
done
flag is more for error conditions, such as redirect where you want to skip something like a logging step.Best practice is to design your functionality as reusable WebMods that use modBase and modRel without assumptions of their top level URI. Then glue everything together with a top level Mod (typically in just a boot script) and typically we just make "/" and "favicon.ico" a special case there.
KevinKelley Thu 11 Feb 2010
Thanks, figured I must be going against the grain somehow.