Utility for creating an Rpc handler specifically for serving static assets. The resolver's path argument is used as the asset path.

Utility for creating an Rpc handler that always redirects. If an origin isn't provided in the redirect url, the origin of the request will be used. Paths can also be relative; if the path starts with a ".", the path will be joined with the pathname of the request using the std path.join() function. If the status isn't provided, 302 is used. Note that paths with trailing slashes will be redirected first to the path without the trailing slash before being redirect to the specified destination. (2 hops)

Creates an endpoint handler for resolving Requests into Responses.

Constructs a new RpcInit. This simply returns the first argument, it's only provided for typing purposes so that you don't need to manually specify the type parameters.

In Cav, there is no middleware. To fill the gap, Rpcs can leverage Ctx functions to create context-dependent data related to a request. These functions are where you'd set up databases, create session objects, etc. The value returned from this function is available as the ctx property for the various Rpc event handler functions.

Arguments available to the Ctx function of an Rpc.

After an Rpc matches with an incoming request, the Resolve function is responsible for resolving the request data into a response to send back to the client. The value returned from the Resolver will be packed with the top-level response() function, i.e. it undergoes packing via packBody().

Arguments available to a Resolver function.

Handler for handling errors that occur during response resolution. Meant to turn the errors into responses to send back to the client, using the same serialization process and utilties available in the resolve function. If an error is re-thrown, that error will be serialized as the response.

Arguments available to the OnError function of an Rpc.

An http.Handler constructed by an RpcFactory. Rpcs are one of two fundamental building blocks of Cav server applications, the other being Stacks. Rpcs are responsible for handling a request, and Stacks are responsible for routing a request to the appropriate Rpc. Once a Request reaches an Rpc and the Rpc's path matches the request, the Rpc is expected to handle all errors and return a Response. If the path doesn't match the Rpc's path, the special NO_MATCH error will be thrown. Uncaught errors bubble up to and are handled by the top-level Server, which will log them and respond with a 500 Response.

Initializer options when constructing Rpcs.

Alias for an Rpc with any resolver or init types. Useful for type constraints.

Matches any given RpcInit. Useful for type constraints.

Initializer options for the assets() utility function.