Fork me on GitHub

Is there a way to customize what reitit does with certain handler return values? For example, if I return an Anomaly map, I want reitit to convert it to an HTTP status code and return the data in the body.


Is there any way to serve multiple vhosts out of one route tree in Reitit? Or would I need to add my own wrapping function to dispatch on :host?


@kenny you can use the interceptor context debugger to see how the context changes, info here


Wow, that’s pretty cool!

partywombat 4

the transformation of return values… that should happen at request processing time, best done in an interceptor. If only your handler can return that, just put an custom interceptor to the last in the stack


if that can be returned from any of the interceptors, you can either: interleave a custom Anomaly->Context transforming interceptor between each other interceptor or you could extend the AsyncContext protocol in Sieppari to make the interceptor engine do it for you. There are examples for the latter in the Sieppari code base, where core.async, manifold & promesa mappings are done.


how to add an interceptor to last in each chain? use an interceptor chain transfomer, they compose too 🙂


that happens at router creation time, so kinda fast too.


@danielcompton sorry, haven’t done that, so not supported out-of-the-box. Today, you need to wrap the top-level handler into something that routes based on the :host.


If that is important, there could be support to plug that into reitit. tested similar already with pohjavirta async dispatch: a custom top-level wrapper that pull the route data from underlaying router and re-creates multiple routers based on some data. In my test there was :server/pool route key to mark in which pool the routes are applied. Can run some routes in a NIO pool, some in the default worker, some in custom bounded pool.


something like that could work with the :host; someone should just finalize the extension thingie first 🙂


Is the recommended testing method to simply call your ring handler with a "partial" request map? e.g.

(app {:request-method :get, :uri "/api/admin/users"})
In the past I've had to use request mocking libraries that fill in a bunch of extra info.


@kenny we have been mosly using just literal maps without any extra libs, makes it explicit what the request looks like. But whatever works for you. If you async things, then you need to deref the response. Test are documenting ways to do that


If I assoc a :response onto the ctx within an interceptor, the chain continues to execute. This is not ideal for an interceptor that does authentication and needs the chain to halt when a request is not authenticated. I have seen but it appears like it will exhibit the same problem I am running into -- the auth-interceptor will still call the :handler even though it assoc's a :response onto the ctx when roles is not a subset of user-roles.


Here's an example. If I call app, I will get the response from my handler, not my interceptor:

(app {:request-method :get
      :uri            "/ping"})
"auth enter"
=> {:status 200, :body "pong2", :headers {}}


@kenny you need to empty the :queue to terminate. E.g. (assoc ctx :queue nil). Sorry for the shitty docs on interceptors.


This worked. Thanks


Won't this remove all other :leave interceptors though?


no, they are pushed to :stack once executed. When queue is empty the stack will be run (leaves or errors)


It looks like it will. This means that all the coercion stuff won't work.


hmm. should not


Hmm, I'm getting this

java.lang.IllegalArgumentException: No implementation of method: :write-body-to-stream of protocol: #'ring.core.protocols/StreamableResponseBody found for class: clojure.lang.PersistentArrayMap
Once I set the :queue to nil. I've seen this before when either a content-type is set to text/plain or the coercion interceptor isn't there.


After doing this in my interceptor:

(assoc ctx
  :response {:status  403
             :body    {:error "forbidden"}}
  ;; empty the interceptor queue to stop processing
  :queue nil)


you should have the response formatter before that in the chain


Look at the http-swagger example app with the context diffing on. It has a "good chain in order".


Sadly, the order matters here


Ah, right. That did it.


So really all my custom interceptors should go below those?


depending on what they do. If they need response formatting, they should be after the formatter


Exception handler should be just after response formatter so it captures all things, but gets formatting itself.


Sieppari will get a 1.0.0 release, hopefully soon. With docs on par rest of the reitit.


I am getting a StackOverflowError when using a spec defined in edn-query-language ( My route has the :parameters set to {:body ::eql-body-params}. Where ::eql-body-params is defined as:

(s/def ::q ::eql/query)
(s/def ::eql-body-params
  (s/keys :req-un [::q]))
Guessing there is some sort of bug or incompatibility of spec-tools with certain specs.


spec-tools is external to spec itself, and uses best-effort parsing of specs to figure out what to do. please add an issue to spec-tools if you can isolate a small/minimum thing that fails.


Yeah I'm starting to realize that. I'll try to make a min repro. Really wish spec2 was out because this sort of stuff is super valuable for us.


proposed a patch to spec some years ago to add support for this, no luck. there is an open issue about a generic walker, hopefully pops up some day. Would be happy to get rid of most of the archeology from spec-tools.


I've seen that one. Isn't spec2 supposed to have some sort of ast to better support these use cases?


How do you enable CORS?


@kenny could you use a standard Ring middleware for CORS?


Perhaps. Trying to follow along here It's not clear how that plays with interceptors though.


Wrote this interceptor. @ikitommi Any interest in a PR to include this in reitit-interceptors?