HTTP message attributes

[gmethvin]

It would be nice if we could attach arbitrary typed values to Akka HTTP requests and responses. This could be used for things like tracking request ids/metadata, and perhaps for other things people are currently using custom headers for.

For example:

// This is a type-safe key to retrieve the attribute
// The String ID is a unique identifier for this attribute
val RequestId: Attr[UUID] = Attr("com.example.foo.bar.RequestId")

// get a new request with the RequestId attribute added
val requestWithId = request.withAttr(RequestId, UUID.randomUUID)

// get the attribute from the request
val requestId: UUID = requestWithId.getAttr(RequestId)

Ideally the API should be type safe so I can only assign an Attr[A] to a value of type A, but if it were possible to write a type-safe wrapper that would probably be sufficient.

My future use case for this would be allowing us to completely represent a Play request as an Akka HTTP request, attaching various Play metadata as attributes.

[ktoso]

Agreed, we currently work around this by having synthetic headers which isn't the most hygienic way to go around it and leaks sometimes.

FYI @bantonsson @jrudolph

[sarahgerweck]

This would be fantastically useful. 👍

[scr-oath]

I was thinking it would be useful to stash values on the RequestContext so that any Directive could access/modify/extract these values to communicate with other Directives. An example is for logging - it would be great if you could set up one outer log directive over a Route.seal of all the routes unioned together with ~ and the log could look for more info on the context that was added by routes (or not) and augment what gets written accordingly. The idea being to have some sort of access-log type thing which is one line of some json-object for easy parsing by things like splunk, e.g. to be queried as desired.

Ultimately I don't care if this hangs off the RequestContext or the request (which hangs off the RequestContext), but I thought it seemed more natural to be on the context object than the request, which could be left unaltered from its initial state.

[johanandren]

For me that sounds an awful lot like the request context of Servlets/JSP (or thread local for that part). Wouldn't it be better to use functional composition and explicit state passing for these kind of things than an arbitrary map of things in context?

[jrudolph]

@scr-oath, the whole routing layer uses immutable data structures (aside from the streaming aspects). So, it will not be possible to mutate things in inner directive and have access to it from outer directives.

What you can do already now is to add custom headers to a request or a response:

• Add it to the request to pass info from the outside to inside routes
• Add it to the response to pass info from the inside to outside routes

This already works now but is a bit cumbersome because you need to define custom headers (though, note, that this is how HTTP works in general. E.g. in proxied setups, the proxies also add headers to requests and may read responses to communicate with backend servers).

This ticket describes that we want to introduce another structure, similar to custom headers that simplifies passing around information inside of Akka HTTP but the concept will exactly be the same as with custom headers.

[scr-oath]

Ok I understand the thirst for immutable rather than the Von Neumann style. Then, I suppose this change/feature-request would be to add arbitrary objects to the request/response (not just strings) and not to the headers (because they're not destined for output)? That would really be great! FWIW, the custom headers approach does work, but is just cumbersome it seems… so this attr idea of arbitrary non-rendered stuff would be a nice addition.