[undertow-dev] More rewrite handler testing and questions

Stuart Douglas sdouglas at redhat.com
Thu Jul 9 20:05:17 EDT 2020


On Fri, 10 Jul 2020 at 02:44, Brad Wood <bdw429s at gmail.com> wrote:

> So, in my bid to put the predicate language through the paces, I've been
> testing out all the rewrite rules I've ever used with mod_rewrite or Tuckey
> Rewrite to see if Undertow's handlers are up to the task.
>
> I've run into an issue again with probably the most common rewrite rule of
> any CFML app using an MVC framework, which is a rule that creates so-called
> "SES" URLs and force all requests through a front controller design
> pattern.
>
> Basically
>
> site.com/home/about
>
>
> gets rewritten to
>
> site.com/index.cfm/home/about
>
>
> Here you can see how this rule is typically accomplished in Apache httpd,
> Nginx, IIS, and Tuckey:
>
>
> https://coldbox.ortusbooks.com/the-basics/routing/requirements/rewrite-rules
>
>
> The hang up is that* any incoming path that maps to an actual file* skips
> the rewrite rule.  That way* /images/logo.jpg* doesn't get rewritten.
>
> So here was my first stab at it with Undertow's predicate language-- it
> seemed simple enough:
>
> not file and not directory -> rewrite('/index.cfm/%{RELATIVE_PATH}')
>
>
> But our old friend the servlet of course is nowhere to be found since my
> "file" and "directory" predicates were executing in the root handler chain
> so there is no concept of a servlet's context root with which to resolve
> file system paths.
>
> So basically, I understand exactly why this doesn't work, but I feel that
> we need to find a way to make this work.  This is a feature that pretty
> much every rewrite engine I've ever used has-- the ability to test the file
> system to see if a file or directory exists.  Can we discuss the following
> options?
>
>    - Find a way for the root handler chain to access the deployment's
>    resource manager
>
>
The big conceptual problem here is that there can be multiple Servlet
deployments, and the rewrite could change which deployment actually gets
served by the request. You could write a custom predicate to handle this,
but you would need to stick the Servlet deployment in a static variable so
the PredicateBuilder has access to it. We could do it with some API changes
I guess, have the PredicateBuilder accept a Map<String, Object>, so you
could pass in the ServletContext as you are building the predicates.


>
>    - Find a way for the rewrite handler to correctly affect not only the
>    exchange but also (optionally) the HttpServletRequest so it's possible to
>    rewrite the URL inside of the servlet's handler chain. I know for certain
>    this is possible because the Tuckey Rewrite engine is implemented as a
>    servlet filter.
>
> This would be done using RequestDispatcher.forward(), you could write a
handler that uses this, or you could write one that uses the Undertow
specific io.undertow.servlet.api.Deployment#getServletDispatcher() to
re-dispatch without calling forward.

Stuart



> I would prefer the first option since I do like having the predicates in
> the root handler chain so it can run as early as possible.
>
> Thanks!
>
> ~Brad
>
> *Developer Advocate*
> *Ortus Solutions, Corp *
>
> E-mail: brad at coldbox.org
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20200710/1259bbc5/attachment.html 


More information about the undertow-dev mailing list