X-Request-Id Middleware

We’ve got an internally used middleware, and wondering whether this would be useful to contribute back into http4s. The basic concept is, propagate the header from request to response, generating a random UUID X-Request-Id if it wasn’t set.

Gist of the code (older version of http4s as can be seen by presence of .ci): https://gist.github.com/Slakah/f5eb4fbe3c6cc1ed28f8bd66482cd566

Docs:

• Heroku docs on X-Request-Id
• Stackoverflow

Does it also make sense to add official support for the header as well in the headers package, i.e.

package org.http4s
package headers

object `X-Requested-With` extends HeaderKey.Default

Let me know if this is something you’ll be interested in, and I can draft a PR.

[rossabaker]

1. We could punt and just use UUID.randomUUID(), which is improving since it traumatized me, and point people to fuid-http4s for something more customizable for people who run into performance problems.

2. Or we could provide an alternate constructor that takes a F[UUID], and make the default one require Sync[F] to do an F.delay(UUID.randomUUID()). Then people could fix their own contention point without a fuuid dependency, or use whatever fuuid provides.

3. Or we could accept an Eval[Random], with a default Eval.now(new SecureRandom()), and let people bring their own random strategy to the table. But that use of Eval for pooling is shady.

I think I like option 2.

[Slakah]

Implemented by #3487