New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inferred sitelet: "GET /" union case prevents other cases from being parsed #940

Tarmil opened this Issue Apr 23, 2018 · 1 comment


None yet
2 participants

Tarmil commented Apr 23, 2018

When only some union cases have an explicit method, then the other cases are never parsed. For example, given this:

type Fails =
    | [<EndPoint "GET /">] Home
    | [<EndPoint "/about">] About

A GET request to /about is not parsed into About, whereas it should be.

This issue does not manifest in the following variants (ie GET /about is parsed correctly):

// The "/" endpoint accepts any method.
type Succeeds1 =
    | [<EndPoint "/">] Home
    | [<EndPoint "/about">] About

// The "/" endpoint accepts another method.
type Succeeds2 =
    | [<EndPoint "POST /">] Home
    | [<EndPoint "/about">] About

// The "/about" endpoint also specifies a method.
type Succeeds3 =
    | [<EndPoint "GET /">] Home
    | [<EndPoint "GET /about">] About

// The GET-specified endpoint is on another path than "/"
type Succeeds4 =
    | [<EndPoint "GET /home">] Home
    | [<EndPoint "/about">] About

@Tarmil Tarmil added the bug label Apr 23, 2018

@Tarmil Tarmil changed the title from Inferred sitelet: "GET /" union case prevents all other cases from being parsed to Inferred sitelet: "GET /" union case prevents other cases from being parsed Apr 23, 2018

@Jand42 Jand42 self-assigned this Apr 24, 2018

@Jand42 Jand42 closed this in c0882fb Apr 25, 2018


This comment has been minimized.


Jand42 commented Apr 25, 2018

Server-side inferred unions uses a forward-only parsing for performance with some heuristics to look for longer matches first. (One union case parsing a sub-path of another is recommended against.) But when there was a method match, it did not look further, now it is also looking up all non-explicit-method cases for when there is a method match.

@Tarmil Tarmil added the label May 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment