giraffe-fsharp/giraffe.tokenrouter

Alternative routing API for Giraffe web applications which is aimed at maximum performance.

giraffe.tokenrouter's Issues

TokenRouter needs explicit GET when POST is used

Originally created by @forki in giraffe-fsharp/Giraffe#158

---

Reminder for @gerardtoconnor ;-)

sent you actual routes in screenshot. It's along the lines of:

 router notfound [
      subRoute "/api" [
           // get routes
           route "/hey" f
           POST [
              route "/there" f2
           ]
 ]

not working. but following is:

 router notfound [
      subRoute "/api" [
           GET [
               route "/hey" f
           ]
           POST [
              route "/there" f2
           ]
 ]

Add Fact

Giraffe.TokenRouter/tests/Giraffe.TokenRouter.Tests/TokenRouterTests.fs

Line 1499 in 9bbdaab

member __.``Test routePorts function`` () =

Support for short GUIDs

I attempted to use a short GUID with the token router, and it didn't like it. I checked, and sure enough, this one doesn't support it - yet. Would you entertain a PR for it?

My thought was to check in the GUID parsing logic to see if the captured length was 22 characters, and if so, run it through ShortGuid.toGuid. It may not be the most efficient way to do it (I imagine there's a reason it doesn't use Guid.TryParse on the chunk of captured data), but it would provide support for the format.

It might not be too tough to parse through it in chunks of 4 characters, and grab the bits from there via a lookup table. The lookup table part makes me wonder how efficiently it could be done. I'm definitely not too strong with bit-shifting.

Anyway, let me know. I don't know that I could turn it really quick, but I think it wouldn't take too long.

Giraffe.TokenRouter

Giraffe.TokenRouter 1.0 crashes on runtime when used in combination with Giraffe 5 since it can't load Giraffe 2.0 lib.

Could you please release a version which depends on Giraffe 5?

Routing - no result on similar routes with first letter collision

I have unfortunately hit a rather subtle bug around similar routes and I am having trouble getting to the bottom of the route cause (there is quite a lot going on in the underlying algorithm that might make more sense to someone who knows the codebase). I am happy to dig in further but I may need a little help!

I have written a failing test that demonstrates the scenario:

[<Fact>]
let ``GET Similar routes should correctly resolve`` () =
    let ctx = Substitute.For<HttpContext>()
    let app =
        router notFound [
            GET [
                routef "/api/%s" (fun _ -> text "a")
                route "/api/csv" (text "b")
            ]
        ]

    ctx.Request.Method.ReturnsForAnyArgs "GET" |> ignore
    ctx.Request.Path.ReturnsForAnyArgs (PathString("/api/cat")) |> ignore
    ctx.Response.Body <- new MemoryStream()
    let expected = "a"

    task {
        let! result = app next ctx
        match result with
        | None     -> assertFailf "Result was expected to be %s" expected
        | Some ctx -> Assert.Equal(expected, getBody ctx, true)
    }

It looks like it is the first character of route segment that seems to be the issue here. If the first char is the same, it seems to bypass both routes and return NotFound. If I change either the positional parameter to "bat" for example, the example works.

In more complex scenarios this is leading to all sorts of problems. In my real app i have various routes like /api/guid/whatever, which seem to be spontaneously failing when using specific GUID's, which I have now discovered is because I have fixed routes of /api/{prefix}..../ which are colliding.

Please let me know where is best to go from here - I am happy to submit a PR with the failing test etc.