Unsupported method OPTIONS

[nodexpertsdev]

Krakend is not able to support OPTIONS HTTP method, I have been trying to access my graphql server (via krakend) with apollo client UI. Apollo Client calls OPTIONS HTTP API call to graphql server. But when I add OPTIONS endpoint for graphql server, It says Unsupported method OPTIONS.

Here is my krakend config

{
	"version": 2,
	"timeout": "3000ms",
	"extra_config": {},
	"cache_ttl": "300s",
	"name": "GraphQL Service",
	"endpoints": [
		{
			"endpoint": "/graphql",
			"method": "POST",
			"output_encoding": "no-op",
			"extra_config": {},
			"backend": [
				{
					"url_pattern": "/graphql",
					"encoding": "no-op",
					"sd": "static",
					"method": "POST",
					"extra_config": {},
					"host": [
					"http://localhost:5000"
					],
					"disable_host_sanitize": true
				}
			],
			"timeout": "60000ms"
		},
		{
			"endpoint": "/graphql",
			"method": "OPTIONS",
			"output_encoding": "no-op",
			"extra_config": {},
			"backend": [
				{
					"url_pattern": "/graphql",
					"encoding": "no-op",
					"sd": "static",
					"method": "OPTIONS",
					"extra_config": {},
					"host": [
					"http://localhost:5000"
					],
					"disable_host_sanitize": true
				}
			],
			"timeout": "60000ms"
		}
	]
}

Please help on this.

[nekrondev]

I have the same issue.

My Swagger-UI loads from 127.0.0.1:9000, api.json loads via krakend no-op proxy from 127.0.0.1:4242/api.json. Now if Swagger UI tries to POST to e.g. 127.0.0.1:4242/api/v1/demo the web browser first sends an OPTIONS request because of CORS. Howerver reading the source code https://github.com/devopsfaith/krakend/blob/f4c0957b10e4f31ae330a7aa3c48641fbc5907e7/router/chi/router.go#L148 this type of request is not supported breaking CORS plugin.

So at least OPTIONS request type should be allowed returning the need CORS headers if CORS plugin has been enabled.

[kpacha]

CORS requests are supported by the https://github.com/devopsfaith/krakend-cors component.

on the other hand, an OPTIONS request should be handled by the gateway and not passed to a backend... and so far, the main router does not support auto generated responses to OPTIONS requests

[kartikay-nx]

@kpacha I understand that OPTIONS request should be handled by gateway rather than backend, but as per your statement, so far, router doesn't support auto generated responses to OPTIONS requests, so should not it just pass to backend and let backend handle OPTIONS request until router is able to handle OPTIONS requests?

Also I think krakend should add support for GraphQL APIs as well rather than just REST APIs.

[nmehlei]

I am a bit confused about the last two responses. If router does not support responding to OPTIONS requests (yet), does the underlying backend need to support CORS responses (e.g. OPTIONS calls) or is this fully handled by krakend-cors? Does krakend-cors relay it internally to the backend or is the backend already fully abstracted from it? (Speaking of the current state, not as it should be)

[kpacha]

the CORS negotiation is done by the krakend-cors middleware by itself, without interacting with any backend.

usually, the OPTIONS method is also used to discover how many methods a path supports. This is not supported so far by the gateway and won't be passed to the backend (it can't deal with it properly since it doesn't know what is exposed by the gateway)

[nodexpertsdev]

Thanks for the information @kpacha, Can you state by when krakend may support the OPTIONS calls? That is important and at the same time, a required piece for a gateway like this.

[dschanoeh]

Since this issue confused me, I tried to understand the current implementation. My understanding is that krakend will respond to OPTIONS requests in the form of CORS pre-flight requests. This is enabled through the configuration of the krakend-cors middleware. What's currently not supported are responses to other types of OPTIONS requests or forwarding them to backends.

[kpacha]

@nodexpertsdev I think you'll find this PR interesting: https://github.com/devopsfaith/krakend/pull/480

@dschanoeh , yes, that's the current status but we're working on improve it

[alombarte]

Hi, closing the issue as this has been supported for a long time already: https://www.krakend.io/docs/service-settings/router-options/#auto_options

[mila-rodriguez-netapp]

Hi, closing the issue as this has been supported for a long time already: https://www.krakend.io/docs/service-settings/router-options/#auto_options

So if I want to handle my own options requests by forwarding them to my backends instead of relying on the incorrect "auto" ones generated by that configuration, I need to open a new feature request?

[alombarte]

Hi @mila-rodriguez-netapp, that would be a new feature request, but we are not going to add it (at least in the mid-short term) on Lura because it only makes sense in a pure reverse proxy context, and this is not the aim or goal of Lura.

The auto-generated ones are not the incorrect ones, on the contrary, if they are open an issue to review it.

When your backend replies with a set of OPTIONS, it returns the options the backend knows, but it does not need to match with the gateway contract, which is completely unrelated. The backend is one possible source of data for the contract, but not the only one (unless of course you treat Lura as a reverse proxy)

[github-actions[bot]]

This issue was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.