possible to configure something like x-server-raw-request ?
I see that x-server-raw-response is available to expose the underlying to users, allowing deeper customization of response.
I was wondering if it's possible to expose a similar interface for request as well? So that we can utilize some predefined functions by akka-http. For example, extractClientIP.
Not a huge deal and is blocking anything, since we can simply replicate all these functions, but would be a helpful feature to have :)
I guess this is already somewhat possible, as if you get a status code that's not in your spec, you just get the object as a Left.
That being said, for your use case, looking at [the docs] (https://doc.akka.io/docs/akka-http/current/routing-dsl/directives/misc-directives/extractClientIP.html), it looks like this could just be exposed as a normal header parameter, it would just be a pain to expose all three.
There may be a valid way to write a oneOf to cover all three cases, though, which would be a good use case for exploring better support for oneOf.
Ah, just realized the motivation behind this, considering #572. Yeah, until that gets fixed the only workaround would be to only specify response codes that you won't actually receive, then handle the success responses manually in the Left that comes from the client call.
thanks. Just in case it's not that clear, I was looking for HttpRequest to be added to the interface on the server side. For example, with that option x-server-raw-request enabled, instead of getting
def getUser(respond: ControlResource.getUserResponse.type)(userId: String): Future[ControlResource.getUserResponse]
the generated code looks like.
def getUser(respond: ControlResource.getUserResponse.type)(userId: String, request: HttpRequest): Future[ControlResource.getUserResponse]
even though userId has been extract from this request, keeping the raw request gives us more room for customization.
I could use this feature as well as it might allow me to circumvent the problem I'm facing in https://github.com/twilio/guardrail/issues/552#issuecomment-634460237