Fix handling of wildcard route requests ending in slash; v0.5.4 #51
Conversation
A wildcard match like /some{/foo} or /some/{+bar} should match even if
the optional component is empty (ex: request for /some/). {+bar} should
also match arbitrary paths ending on a slash (ex: /some/path/).
|
/cc @wikimedia/services |
|
This fixes an issue I ran into while testing node-serviceworker-proxy, where requests for URLs ending in slash would return an empty path listing instead of hitting the serviceworker. |
|
Looks good. We won't be able to distinguish |
|
|
|
@gwicke Right, just since now |
Yeah, that's a good point. I tried to generally order things a while ago in order to make this deterministic, but IIRC that didn't work out so easily. |
|
We don't have cases like this anyway, so we're fine. |
|
Published & tagged. |
wikimedia/swagger-router#51 changed the handling of overlapping routes ending in a slash. As a result, we now need to list the higher level route first, to avoid conflicts during tree construction.
2 participants
A wildcard match like /some{/foo} or /some/{+bar} should match even if
the optional component is empty (ex: request for /some/). {+bar} should
also match arbitrary paths ending on a slash (ex: /some/path/).