Http OPTIONS not triggering the REST resource

, , , ,
1

Hi All: I have a situation where the partner will be sending the HTTP OPTIONS before sending actual POST body . we need to send them a "custom header back when they srnd http OPTIONS. when i test from postman it shows 200 OK for OPTIONS but it doesn’t triggger the _default. But I am not able to capture the savepipeline, I mean it doesn’t kick in the REST method. I am not sure maybe server is responding with 200 and not letting the OPTIONS hit the code. I created _post and _default event. What extended settings do I need to add. I have the below at the moment.

watt.server.cors.allowedOrigins=*
watt.server.cors.enabled=true
watt.server.cors.exposedHeaders=
watt.server.cors.host=
watt.server.cors.maxAge=-1
watt.server.cors.supportedHeaders=Accept,Cache-Control,authorization,samlassertion,Content-Type,content-type
watt.server.cors.supportedMethods=GET,POST,PUT,DELETE,OPTIONS,HEAD
watt.server.cors.supportsCredentials=false

2

Hi Kumar,

Please note that OPTIONS does not transfer control to your REST resources.

Regards,
-Kalpesh.

3

Hi Kumar,

See if you can use _default service to have a logic to send the desired response if $httpMethod=OPTIONS in the request itself.

For _default, $httpMethod is a required parameter that the client need to send.

Regards,
Firoz N

4

Thanks Kalpesh! So, there is no way that it will hit the REST resource. I mean, is it limitation in webMethods.

5

I tried, but nothing working.

6

Hi Kumar,

Yes, this is the current behavior and follows HTTP spec defined @ HTTP/1.1: Method Definitions.

Regards,
-Kalpesh.