watt.server.cors.supportedHeaders Case Sensitive?

RFC 2616 states: “Each header field consists of a name followed by a colon (”:") and the field value. Field names are case-insensitive."

However, when I called a REST service on IS, I received the following error:

  • Header: “HTTP/1.1 403 Header not supported”
  • Logs: [275]2017-12-13 11:05:46 AEST [ISS.0152.8002W] Header not supported : content-type

Request Headers:

OPTIONS https://site/rest/service.search HTTP/1.1
Host: host:port
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36
Access-Control-Request-Headers: content-type
Accept: /
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8

Exiting settings:

watt.server.compile=E:\SoftwareAG\jvm\jvm\bin\javac -classpath {0} -d {1} {2}
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
watt.server.cors.supportedMethods=GET,POST,PUT,DELETE,OPTIONS,HEAD
watt.server.cors.supportsCredentials=false

Looks like a bug. Fix is to add lower-case content-type.

1 Like

Hi Peter,

Thanks for this post. we had similar issue today when the REST call invoked from Chrome (Chrome sets the header to content-type Instead of Content-Type), when we add the one (with lower case) which you had shared earlier in this post, it started working.

watt.server.cors.supportedHeaders=Accept,Cache-Control,authorization,samlassertion,Content-Type,content-type

Thank you!

Thanks,
Arul

SAG should have fixed this issue (no need to add the extended setting) and here are the details, may i know your IS version.

Version 10.1: Corrected with IS_10.1_Core_Fix12 or higher
Version 10.3: Corrected with IS_10.3_Core_Fix4 or higher

Hi Mahesh,

Our IS version is 9.12 (with latest fixes) and may be that’s the reason we need to set manually for now. Thanks!

Thanks,
Arul

Arul, Mahesh and Peter: I have a situation where the partner will be sending the HTTP OPTIONS – but we’re sending him the 200 OK. But I am not able to capture the savepipeline, I mean it doesn’t kick in the REST method. I am not sure. 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