[ 
https://issues.apache.org/jira/browse/CAMEL-26460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-26460.
---------------------------------
    Resolution: Fixed

Fixed by https://github.com/apache/camel/pull/29039

> camel-undertow - a path template and a static path of one base path: wrong 
> route for the base path, and stopping the template route drops the static path
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-26460
>                 URL: https://issues.apache.org/jira/browse/CAMEL-26460
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-undertow
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Major
>             Fix For: 4.24.0
>
>
> When one route consumes a path template (such as 
> {{undertow:http://0.0.0.0:8080/orders/\{id\}}}) and another route a static 
> path of the same base path ({{/orders}}, exact or with 
> {{matchOnUriPrefix=true}}), {{CamelRootHandler}} serves both through one 
> {{CamelPathTemplateHandler}} registered as the prefix path of the base path, 
> with the static path as its default handler. {{CamelPathHandler}} keeps one 
> map of path to handler for the exact and the prefix paths, and only counts 
> the templates when one is removed:
> * *Wrong routing while both run.* When the template route starts first, a 
> request for {{/orders}} is answered by the template route with an empty 
> {{id}}: Undertow matches the empty rest of the base path against {{/\{id\}}}. 
> The same happens for {{/items}} when a {{matchOnUriPrefix}} route of 
> {{/items}} started before the template route of {{/items/\{id\}}}. The same 
> for {{/orders/}} and for {{/}} with a {{matchOnUriPrefix}} route of {{/}} and 
> a template {{/\{id\}}}. When the static exact route starts first, {{/orders}} 
> reaches it, as Undertow's exact path wins.
> * *Stopping the template route drops a prefix path.* With 
> {{/items?matchOnUriPrefix=true}} started before {{/items/\{id\}}}, stopping 
> the template route removes the prefix path of {{/items}}, so {{/items/a/b}} 
> gets 404 while the {{matchOnUriPrefix}} route runs.
> * *Stopping the template route stops the server of a running route.* With the 
> static exact route started first, the template's prefix path replaces the 
> exact path in the map of {{CamelPathHandler}}; with the template route 
> started first, the static path lives only in the default handler of the 
> template handler. Either way, when the template route stops, the map is 
> empty, so {{DefaultUndertowHost}} stops the server when these were its only 
> paths: the static route still runs, and its requests get "connection refused" 
> (with other paths on the server, {{/orders}} gets 404 in the second order).
> Plain (not rest-dsl) path templates; rest-dsl consumers go through 
> {{RestRootHandler}} and are not affected.
> *Proposal*
> * {{CamelPathHandler}} keeps the exact and the prefix paths apart, and 
> {{isEmpty()}} counts both.
> * A static exact path added after the templates of its base path is 
> registered as an exact path too, as when it comes first.
> * {{CamelPathTemplateHandler}} answers a request for the base path itself 
> with the static path of the base path when there is one.
> * When the last template of a base path is removed, a static prefix path is 
> registered as the prefix path again, and an exact one stays; removing a 
> static path removes the registration its handler has.
> * A {{matchOnUriPrefix}} route of the base path declared after the template 
> route is refused today ({{Duplicate handlers on a path}}, the CamelContext 
> does not start), while the other order works: accept it as the static path of 
> the base path when the base path has none yet.
> * Tests with routes on one server for both start orders, stopping and 
> starting each route, and a server whose only paths are the static path and 
> the template.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to