query parameter parsing and Dancer vs Apache handling
Hi Dancers, Is it possible to have Dancer selectively handle some routes based on query parameters, and leave others for another script to handle? I'm working with an old site where some URLs with query params of the form main.cgi?param=value¶m2=value2¶m3=value3 can be handled by Dancer (by redirecting to new pages), but others must be handled by the old site. At present, I have a route set up to parse query params for /main.cgi, and any query params that Dancer can't handle go to the 404 page. Is there are way to let those queries 'pass through' dancer (i.e. not trigger a 404) and be handled by the perl script main.cgi instead? If I set up Apache or my psgi application to send all those queries to main.cgi first, the subset of pages that can be redirected by new pages will just show the old page. Unfortunately I cannot change the content of the old pages to change the URLs. I'd guess I can create Apache redirects for sets of query parameters -- it's pretty easy to specify that only certain combinations of query params are handled by Dancer, and I'm not sure it is as easy a task with Apache. Thanks!
On May 15, 2017, at 11:40 AM, Amelia Ireland <aireland@lbl.gov> wrote:
I'm working with an old site where some URLs with query params of the form
main.cgi?param=value¶m2=value2¶m3=value3
can be handled by Dancer (by redirecting to new pages), but others must be handled by the old site.
I’d handle that at the front-end proxy layer, with each URL type reverse-proxyied to the appropriate Dancer app instance. mod_proxy in Apache and its equivalent in nginx should be capable of distinguishing the URL types. To do it entirely within Dancer, I think you’d end up building a reverse proxy layer within one of the Dancer apps and thus causing one Dancer app to be subordinate to the other, and that just is not an efficient thing to be doing in Perl.
participants (2)
-
Amelia Ireland -
Warren Young