hmm, bit of a strange one, using compojure-api resources in front of my liberator resources , in liberator i’m setting CORS headers for all responses (access-control-allow-origin etc) , these are being returned correctly for all request methods except for OPTIONS , where they are not being returned at all

example of how i’m defining the compojure-api resource:

(defn site-resource [db-spec]
  (api/resource
    {:tags ["sites"]
     :description "Sites"
     :head {:summary "Return HTTP Headers"
            :responses {status/ok nil}}
     :options {:summary "Return available HTTP OPTIONS"
               :responses {status/ok nil}}
     :get {:summary "Return Site records, optionally filtered by URL parameters."
           :parameters {:query-params SiteQueryParams}
           :responses  {status/ok {:schema SiteArrayResponse}}}
     :post {:summary "Create a new Site record."
            :parameters {:body-params Site}
            :responses  {status/created {:schema SiteCreated}}}
     :handler (site db-spec)}))

doesn’t seem like it should be required to specify these headers in my responses since they are being returned fine for everything other than OPTIONS

@d5p I’ll have a look

thanks, i’m poking around the source trying to follow the execution path but yeh taking a bit to get my head around it 🙂

it is returning an Allow header for OPTIONS that i’m not generating in my liberator resource as well

hmm… the resource isn’t doing anything extra, just coercion and selecting the right handler.

if you call the liberator resource directly, it works ok?

yeh

and actually just stuck a debug log in , on OPTIONS it doesn’t appear to be calling my liberator handler at all

any middleware further up the chain that would be using the keys in my resource definition to generate the Allow header? as that appears to be what’s happening

hmm… sounds like it. compojure-api doesn’t do anything like that, or shoudn’t at least.

i’m just using api-middleware , so been poking through that

((api
   (context "/" []
     (resource {:handler (fn [_] {:headers "kikka"})}))) 
  {:request-method :options, :uri "/"})
; => {:headers "kikka"}

hmm

that’s the minimalstic set: api + context + resource => nothing looking for OPTIONS.

do you have some extra mw like ring-defaults?

quickly looked at ring code at github, didn’t find anything there either.

nah i removed all other middleware , just have api-middleware , ring-logger and liberator.dev/wrap-trace

still doesn’t work?

nope 😕 yeh odd can’t see anything anywhere that would be swallowing this request

if you replace your liberator handler with something like (constantly {:headers “kikka”}), does it return it?

only place I found any mark of OPTIONS was the Liberator codebase itself, some rules about it: https://github.com/clojure-liberator/liberator/blob/60ca12f12d1a322202de5659b8ab510d9bcc7884/src/liberator/core.clj

is it possible that the liberator resource is consuming it?

https://github.com/clojure-liberator/liberator/blob/60ca12f12d1a322202de5659b8ab510d9bcc7884/src/liberator/core.clj#L462

hmm no when i replace my liberator resource with :handler (constantly {:headers “kikka”}) i get a 500 java.lang.UnsupportedOperationException: nth not supported on this type: Character

ah, should be something like (constantly {:headers {”kikka” “kukka”}})

was running from repl, so no ring-adapter there

yeah hmm so that works fine

hmm, actually before i misspke , my handler was getting called , i can see my liberator decision graph , it just wasn’t getting to the response handler which works ok when i wasn’t using compojure-api

strange so :as-response which lets me send back through the raw response , is called when i use the liberatr resource directly , for some reason not being passed back now

ha ahh well will continue digging , must be something funky liberator side

is it possible to set custom headers for all compojure-api responses? could always move the logic there

sure, just add a middleware somewhere into the request pipeline.

ah yeh sweet

great thanks

np