org.http4s.server.middleware

Removes a trailing slash from Request path

If a route exists with a file style Uri, eg "/foo", this middleware will cause Requests with uri = "/foo" and uri = "/foo/" to match the route.

Middleware for caching the request body for multiple compilations

As the body of the request is the fs2.Stream of bytes, compiling it several times (e.g. with middlewares) is unsafe. This middleware forbids such behaviour, compiling the body only once. It does so only for the "inner" middlewares:

val route = AMiddleware(BodyCache(SomeOtherMiddleware(myRoute)))

In this example only myRoute & SomeOtherMiddleware will receive cached request body, while the AMiddleware will get the raw one.

As the entire request body will be allocated in memory, there is a possibility of OOM error with a large body. Because of that, using the EntityLimiter middleware is strongly advised.

Middelwares which allow for bracketing on a Request/Response, including the completion of the Response body stream.

These are analogous to cats.effect.Bracket and fs2.Stream.bracket. The reason that they exist is because due to the full termination of a Response being a function of the termination of the fs2.Stream which backs the response body, you can't actually use either cats.effect.Bracket or fs2.Stream.bracket directly.

Implements the CORS protocol. The actual middleware is a CORSPolicy, which can be obtained via policy.

A middleware that applies the CORS protocol to any Http value. Obtain a reference to a CORSPolicy via the CORS object, which represents a default policy.

Requests with an Origin header will receive the appropriate CORS headers. More headers are available for "pre-flight" requests, those whose method is OPTIONS and has an Access-Control-Request-Method header.

Requests without the required headers, or requests that fail a CORS origin, method, or headers check are passed through to the underlying Http function, but do not receive any CORS headers in the response. The user agent will then block sharing the resource across origins according to the CORS protocol.

Middleware to avoid Cross-site request forgery attacks. More info on CSRF at: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

This middleware is modeled after the double submit cookie pattern: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie

When a user authenticates, embedNew is used to send a random CSRF value as a cookie. (Alternatively, an authenticating service can be wrapped in withNewToken).

By default, for requests that are unsafe (PUT, POST, DELETE, PATCH), services protected by the validated method in the middleware will check that the csrf token is present in both the header headerName and the cookie cookieName. Due to the Same-Origin policy, an attacker will be unable to reproduce this value in a custom header, resulting in a 403 Forbidden response.

By default, requests with safe methods (such as GET, OPTIONS, HEAD) will have a new token embedded in them if there isn't one, or will receive a refreshed token based off of the previous token to mitigate the BREACH vulnerability. If a request contains an invalid token, regardless of whether it is a safe method, this middleware will fail it with 403 Forbidden. In this situation, your user(s) should clear their cookies for your page, to receive a new token.

The default can be overridden by modifying the predicate in validate. It will, by default, check if the method is safe. Thus, you can provide some whitelisting capability for certain kinds of requests.

We'd like to emphasize that you please follow proper design principles in creating endpoints, as to not mutate in what should otherwise be idempotent methods (i.e no dropping your DB in a GET method, or altering user data). Please do not use the CSRF protection from this middleware as a safety net for bad design.

Caching contains middlewares to support caching functionality.

Helper functions to support Caching.cache can be found in Caching.Helpers

Generic middleware to aggregate chunked response into memory.

This middleware wraps any function that may produce an Http response. Upon receiving a chunk-encoded response, the composed function will pull and assemble the full response into memory before emitting the whole response. It also removes the "Chunked encoding" headers, and may add a Content-Length header for the whole payload.

Reference: "Chunked Transfer Encoding", Section 4.1 of RFC 7230 https://datatracker.ietf.org/doc/html/rfc7230#section-4.1

Middlewares for tracking the quantity of concurrent requests.

These are generalized middlewares and can be used to implement metrics, logging, max concurrent requests, etc.

Date Middleware, adds the Date Header to All Responses generated by the service.

Handles HEAD requests as a GET without a body.

If the service returns the fallthrough response, the request is resubmitted as a GET. The resulting response's body is killed, but all headers are preserved. This is a naive, but correct, implementation of HEAD. Routes requiring more optimization should implement their own HEAD handler.

Middleware to add HTTP Strict Transport Security (HSTS) support adding the Strict Transport Security headers

Middleware to redirect http traffic to https. Inspects X-Forwarded-Proto header and if it is set to http, redirects to Host with same URL with https schema; otherwise does nothing. This middleware is useful when a service is deployed behind a load balancer which does not support such redirect feature, e.g. Heroku.

Middleware to support wrapping json responses in jsonp.

Jsonp wrapping occurs when the request contains a parameter with the given name and the request Content-Type is application/json.

If the wrapping is done, the response Content-Type is changed into application/javascript and the appropriate jsonp callback is applied.

Simple Middleware for Logging All Requests and Responses

Server middleware to record metrics for the http4s server.

This middleware will record:

• Number of active requests
• Time duration to send the response headers
• Time duration to send the whole response body
• Time duration of errors and other abnormal terminations

This middleware can be extended to support any metrics ecosystem by implementing the org.http4s.metrics.MetricsOps type

Propagate a X-Request-Id header to the response, generate a UUID when the X-Request-Id header is unset. https://devcenter.heroku.com/articles/http-request-id

Simple Middleware for Logging Requests As They Are Processed

Simple middleware for logging responses as they are processed

Simple middleware for adding a static set of headers to responses returned by a kleisli.

Transform a service to reject any calls the go over a given rate.

Removes the given prefix from the beginning of the path of the Request.

Middleware for lifting application/x-www-form-urlencoded bodies into the request query params.

The params are merged into the existing paras after the existing query params. This means that if the query already contains the pair "foo" -> Some("bar"), parameters on the body must be acessed through multiParams.

Middleware for virtual host mapping

The VirtualHost middleware allows multiple services to be mapped based on the org.http4s.headers.Host header of the org.http4s.Request.

CORS middleware config options. You can give an instance of this class to the CORS middleware, to specify its behavior