A normal WAI Request and the parsed post body (if present). We can only parse the body once, so we need to have our request (which we pass around) to be able to have the parsed body.

A default request, which is a WAI defaultRequest and a place for an MVar where post info will be placed (if you parse the post body).

Warning: If you try to parse the post body (with !=>) without replacing the Nothing placeholder with an actual MVar, it will blow up!

Specify the way that Fn can get the FnRequest out of your context.

The easiest way to instantiate this is to use the lens, but if you don't want to use lenses, define getRequest and setRequest.

Note that requestLens is defined in terms of getRequest and setRequest and vice-versa, so you need to define _one_ of these.

Convert an Fn application (provide a context, a context to response function and we'll create a WAI application by updating the FnRequest value for each call).

The parts of the path, when split on /, and the query.

The type of a route, constructed with 'pattern ==> handler'.

The main construct for Fn, route takes a context (which it will pass to all handlers) and a list of potential matches (which, once they match, may still end up deciding not to handle the request - hence the double Maybe). It can be nested.

 app c = route c [ end ==> index
                 , path "foo" // path "bar" // segment /? param "id ==> h]
   where index :: Ctxt -> IO (Maybe Response)
         index _ = okText "This is the index."
         h :: Ctxt -> Text -> Text -> IO (Maybe Response)
         h _ s i = okText ("got path /foo/" <> s <> ", with id=" <> i)

The route function (and all your handlers) return 'IO (Maybe Response)', because each can elect to not respond (in which case we will continue to match on routes). But to construct an application, we need a response in the case that nothing matched - this is what fallthrough allows you to specify. In particular, notFoundText and notFoundHtml may be useful.

The non-body parsing connective between route patterns and the handler that will be called if the pattern matches. The type is not particularly illuminating, as it uses polymorphism to be able to match route patterns with varying numbers (and types) of parts with functions of the corresponding number of arguments and types.

The connective between route patterns and the handler that parses the body, which allows post params to be extracted with param and allows file to work (otherwise, it will trigger a runtime error).

Connects two path segments. Note that when normally used, the type parameter r is Req. It is more general here to facilitate testing.

A synonym for //. To be removed

Matches a literal part of the path. If there is no path part left, or the next part does not match, the whole match fails.

Matches there being no parts of the path left. This is useful when matching index routes.

Matches anything.

Captures a part of the path. It will parse the part into the type specified by the handler it is matched to. If there is no segment, or if the segment cannot be parsed as such, it won't match.

Matches on a particular HTTP method.

A class that is used for parsing for param and paramOpt. and segment.

Matches on a query parameter of the given name. It is parsed into the type needed by the handler, which can be a Maybe type if the parameter is optional, or a list type if there can be many. If the parameters cannot be parsed into the type needed by the handler, it won't match.

Note: If you have used the !=> connective, so that the request body has been parsed, this will also match post parameters (and will combine the two together). If you haven't used that connective (so the pattern is matched to handler with ==>), it will only match query parameters.

Matches on query parameters of the given name. If there are no parameters, or they cannot be parsed into the type needed by the handler, it won't match.

If the specified parameters are present, they will be parsed into the type needed by the handler, but if they aren't present or cannot be parsed, the handler will still be called.

Note: If you have used the !=> connective, so that the request body has been parsed, this will also match post parameters (and will combine the two together). If you haven't used that connective (so the pattern is matched to handler with ==>), it will only match query parameters.

An uploaded file.

Matches an uploaded file with the given parameter name.

Matches all uploaded files, passing their parameter names and contents.

Serves static files out of the specified path according to the request path. Note that if you have matched parts of the path, those will not be included in the path used to find the static file. For example, if you have a file static/img/a.png, and do:

path "img" ==> staticServe "static"

It will match img/img/a.png, not img/a.png. If you wanted that, you could:

anything ==> staticServe "static"

If no file is found, or if the path has .. or starts with /, this will continue routing.

Sends a specific file specified by path. It will specify the content-type if it can figure it out by the file extension.

If no file exists at the given path, it will keep routing.

Returns Text as a response.

Returns Text as a JSON response with appropriate header.

Returns Html (in Text) as a response.

Returns Text as a response with a 500 status code.

Returns Html (in Text) as a response with a 500 status code.

Returns a 404 with the given Text as a body. Note that this returns a 'IO Response' not an 'IO (Maybe Response)' because the expectaiton is that you are calling this with fallthrough.

Returns a 404 with the given html as a body. Note that this returns a 'IO Response' not an 'IO (Maybe Response)' because the expectaiton is that you are calling this with fallthrough.

Redirects to the given url. Note that the target is not validated, so it should be an absolute path/url.

Redirects to the referrer, if present in headers, else to "/".

Internal helper - uses the name of the file as the pattern.