CORS and Host Header Dilema

Me and a colleague have been trying to troubleshoot a CORS issue we have been having for the last couple of days. After a few days of banging our heads on the keyboard we stumbled across:

If the client is a browser, there is a known issue with this plugin caused by a limitation of the CORS specification that doesn’t allow to specify a custom Host header in a preflight OPTIONS request.

Because of this limitation, this plugin will only work for APIs that have been configured with a uris setting, and it will not work for APIs that are being resolved using a custom DNS (the hosts property).

I am not quite sure how to configure Kong for URIs. I believe I have to set up an upstream and strip the host? Or am I way out in the weeds on this?

Thanks for any help.

I am also looking for this info! It looks like uri is a property of the deprecated APIs object (deprecated after .12x – you can see it here: but services and routes don’t have a uri property.

Pinging @thibaultcha or @jpk … are the choices here to either use a deprecated API endpoint for routes that require OPTIONS? Or is there an undocumented way to set a uri for a service?

Is there a new version of the CORS plugin coming?


Hi there,

The API’s uris attribute became the Route’s paths (it was simply renamed when we split the API entity in Services/Routes).

Note that the API entity is still present (and deprecated) in 0.13 and 0.14, but will be removed in the final 1.0 release.

No, but the plugin is open source and contributions are welcome :slight_smile:

Arbitrary header routing for Kong (on other headers than Host) is how we wish to address this problem. It is in our roadmap but not high enough in our priority list for us to be working on it at this moment. Again, contributions welcome!

1 Like

@emckean This ended up not being my issue at all (or at least not the solution), because I was already using Kong to proxy through to my service in another container.

Our problem was solved by removing the methods from each route for the entire service. I am not sure if that is the way this is intended to be implemented, but I did not question the results after fighting with it for a couple of days.

1 Like

@Darrell_Henderson Did you try adding the OPTIONS method to those Routes? That would be required for the preflight requests to make it through.

It’d be helpful too if you could describe which issue you are encountering precisely. HTTP request, response, Kong configuration, expected behavior, and error logs if any, are all pretty much required if you want help with your issue. Next time!

1 Like

I did try to add OPTIONS but something was not allowing it. However, I am using the Konga UI, and that could be on them.

Thank you! This makes more sense, I will try to see if I can do some edits to the CORS plugin documentation to update it in line with the new Services/Routes naming conventions (but probably not this week)!

All that said, I finally stopped and asked myself if users actually needed OPTIONS or preflighting, checked the CORS documentation & our logs again, and realized that OPTIONS calls were made thirteen times on a typical day (out of ~200K calls) and they were all errors. :face_with_raised_eyebrow:

Thanks again!

Awesome. I was about to come back here and suggest that this should probably be the first step we should take to address the confusion here :slight_smile:


Can you elaborate more on how you resolved host header CORS dilemma?

That was the bug, apparently even though the CORS plugin was well configured, as I had not put the OPTIONS method in the methods accepted by the route, the request to validate the CORS was never being sent, solved after a few days , thanks :+1: