Extracting raw query from request

tapir
1

Hello,

Is it possible to extract whole raw query from request?
I need original query for very specific auth.

I tried using “extractFromRequest” but this changes encoding.
E.g. “q=CUS820038%20MILA01060” is changed to “q=CUS820038+MILA01060”.

2

Which backend are you using? Some underlying servers expose the unparsed data; the original request object is available through extractFromRequest(_.underlying.(...)), and then depending on the specific interpreter you’ll need a cast

3

Thanks! I’m using Akka Http and this worked

request.underlying.asInstanceOf[RequestContext].request.uri.rawQueryString
4

Very interesting, I didn’t know about extractFromRequest at all

I’m currently working on a functionaly to store both request and responses for a specific endpoint in an external database (a sort of auditing system for financial transactions), and thus far the best option I’ve found is using an endpoint interceptor, and then casting request and response.

Now I wonder if there’s a better way for this use-case

5

@gdispada an interceptor (or more specifically, a RequestInterceptor) is I think the best tool for this job. Quite possible, you might not have to cast anything - the ServerRequest exposes most necessary information (including the URI, although in a parsed form), and the RequestResult has the response (if any). You might need some interpreter-specific logic if you need to somehow transform/log the body, but that might have performance implications.

6

@adamw why a request interceptor instead of a endpoint interceptor?

To be honest the documentation I found is not very detailed and I wasn’t able to find any examples (under examples), but I thought the endpoint one would be better suited since

  • I only want to apply the interceptor to a specific endpoint (or list of endpoints < all), which is easy to do with endpoint interceptors as I have context.endpoint. With a request interceptor, I’d have to match on the request uri, which is less refactor-friendly and error prone
  • I do need to store the response body, despite the performance implications

I think that in fact both can work, I can access the response from the RequestInterceptor as well

7

An endpoint interceptor might be called multiple times, for each endpoint that fails to decode first, and then for the endpoint that succeeds. Typically though, only one endpoint is attempted to be decoded, due to path pre-matching.

A request interceptor, on the other hand, is always only called once per request.

But if, as you write, you want to enable this conditionally, then yes, an endpoint interceptor will be the better choice, as you have access to the specific endpoint & its attributes (which are great for storing such flags). There, you should probably ignore the onDecodeFailure callback, and implement the other two.