Fork me on GitHub
#pedestal
<
2018-08-02
>
dadair13:08:49

I’m having an issue getting CORS working; I’ve followed the guides and the service map has ‘:io.pedestal.http/allowed-origins {:creds true :allowed-origins (constantly true)}’, but I get a 404 on browser OPTION pre-flight

dadair13:08:11

Not sure where I’m going wrong here

curtosis16:08:36

@dadair I saw that with pedestal-lacinia. IIRC pre-flight means the browser is rejecting it before sending it along. In my case it was sending a query that didn’t match the API spec. Maybe that helps you narrow down the problem point?

dadair16:08:59

Do I need to define a catch-all :option route? From looking at the pedestal CORS code, I thought it handles all of this in interceptors that are pre-router

dadair17:08:04

Found the problem(s): 1. I was setting the ::http/allowed-origins key after applying the default interceptors function (which relies on the presence of the key to add the appropriate interceptor) 2. I was providing my own :interceptors [] key, which was preventing default-interceptors from defining the defaults to begin-with (I thought this would add, rather than prevent)

👍 4
dadair21:08:11

Are there any unexpected consequences one should be aware of when running multiple pedestal-jetty servers (different ports) in a single JVM? Outside of general performance considerations.

dadair21:08:42

We’re trying to trim our proliferation of services by combining services into a single/less JVMs (we don’t expect huge load). I have multiple servers running, and everything seems to be fine, just wanted to make sure there wasn’t going to be anything biting us in the butt later

jonahbenton21:08:48

You can have as many or as few ports open as you want, and certainly webapp containers usually host many services at once- but logically services can have lots of singleton resources- connection pools, caches, etc- and distinct lifecycles- before this/after that- and dependencies. Obviously there's additional context but my knee jerk would be to make them really one service- one port, one lifecycle, etc, easing the transition pain with a load balancer or proxy if need be- or fitting into the war-container pattern. Two microservices on two ports in one jvm- again absent additional context- feels like a doesn't end well situation to me.