Strange behaviour on greedy routes (/*)

[drakmail]

Description

I have following routes definition:

require "kemal"

get "/*" do
  "default route"
end

get "/refresh" do
  "refresh route"
end

Kemal.run

When I request /request1234 instead of "default route" response I got 404 error page.

Steps to Reproduce

1. Run example
2. curl http://localhost:3000/sometest and get "default route" response
3. curl http://localhost:3000/refresh and get "refresh route" response
4. curl http://localhost:3000/refresh1234 and get unexpected "404 page" response (in html)

Expected behavior: "default route" response

Actual behavior: 404 page in html

Reproduces how often: every time

Versions

$ crystal --version
Crystal 0.26.1 (2018-08-27)

LLVM: 6.0.1
Default target: x86_64-apple-macosx

# shard.lock
version: 1.0
shards:
  exception_page:
    github: crystal-loot/exception_page
    version: 0.1.1

  kemal:
    github: kemalcr/kemal
    version: 0.24.0

  kilt:
    github: jeromegn/kilt
    version: 0.4.0

  radix:
    github: luislavena/radix
    version: 0.3.8

[vladfaust]

Routes are implemented with radix tree; and luislavena’s version doesn’t support wildcards afaik

[codenoid]

the old version is working fine @vladfaust
#497
pls @straight-shoota @sdogruyol

[sdogruyol]

@codenoid which version?

[codenoid]

@sdogruyol master and 0.24.0

[MisterBianco]

Has any headway been made on this? I am experiencing the same issue and would love to clear it up without a super hacky bit of code... ❤️

[mang]

I had a similar issue, where given these routes

get "/:uri" { "1" }
get "/aa" { "2" }

a GET to /a would give 1, /aa would give 2 and /aaa would give a 404.

Seems to be similar to #293

[codenoid]

this is really weird

[benbonnet]

Hi, also getting randomly working greedy routes.
Would sometimes work by simply reordering route order then restarting.
Sometimes not working at all.

[benbonnet]

Unsure if it would give more infos; given that a get wildcard has been defined with
get "/*" { render "src/views/index.ecr" };
the following route : /111/222/333 works. /1/abc/xzy do work too. if it starts with an int, it works.
if starting with a letter /a111/222/333, Kemal doesn't know this way. and so on for anything starting with a letter

[grepsedawk]

This is not occurring for me on the latest release (v1.1.0) with the following test code:

require "kemal"

# Matches GET "http://host:port/"
get "/*" do
  "Wildcard!"
end

get "/asdf" do
  "asdf route"
end

Kemal.run

[benbonnet]

can confirm the encountered issue (/a111/222/333 not working vs. /111/222/333 working) does not happen