watt.server.cors.supportedHeaders Case Sensitive?

,
1

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
2

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

3

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

4

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

5

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