API Gateway removes Access-Control-Allow-Headers header

[akrabat]

Given an action that looks like this:

<?php
function main(array $args) : array
{
    return [
        'statusCode' => 301,
        'headers' => [
            'Location' => '/books',
            'Access-Control-Allow-Headers' => 'Content-Type'
        ],
    ];
}

that's wired up to the API Gateway, I expect to see the Access-Control-Allow-Headers header in the response. Instead it is gone!

Headers in Web Action response:

$ curl -i -H "X-Require-Whisk-Auth: $REQUIRE_WHISK_AUTH" https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/ow-php-bookshelf-backend-dev-root
HTTP/1.1 301 Moved Permanently
X-Backside-Transport: OK OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Server: nginx
Date: Fri, 01 Jun 2018 15:49:32 GMT
X-Request-ID: 908fab442952df93704c73c8a9e9abb3,908fab442952df93704c73c8a9e9abb3
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS, GET, DELETE, POST, PUT, HEAD, PATCH
Access-Control-Allow-Headers: Authorization, Content-Type,Content-Type
Location: /books
IBM_Cloud_Functions: OpenWhisk
X-Global-Transaction-ID: 34285313
Set-Cookie: DPJSESSIONID=PBC5YS:1342728446; Path=/; Domain=.openwhisk.eu-gb.bluemix.net

Headers in the API Gateway response:

$ curl -i https://service.eu.apiconnect.ibmcloud.com/gws/apigateway/api/2fbc … 8be1/ow-bookshelf-todo-backend/
HTTP/2 301
access-control-allow-credentials: true
access-control-allow-methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
access-control-allow-origin: *
content-type: text/plain
date: Fri, 01 Jun 2018 15:50:58 GMT
ibm_cloud_functions: OpenWhisk
location: /books
server: openresty
set-cookie: DPJSESSIONID=PBC5YS:1342728446; Path=/; Domain=.openwhisk.eu-gb.bluemix.net
x-backside-transport: OK OK
x-gateway-host: 10.164.193.60:31353
x-global-transaction-id: 139638815
x-request-id: 9e54ef0ebeafdcfd2ea43d6806820587,9e54ef0ebeafdcfd2ea43d6806820587
x-request-id: nluhqvi9P9YoSXB8gjPTCuatZpU55eUH
content-length: 0

As you can see, the Access-Control-Allow-Headers header that's in the web action response is missing from the API Gateway response.

[rabbah]

side note but why are there two x-request-id fields with values 9e54ef0ebeafdcfd2ea43d6806820587 and nluhqvi9P9YoSXB8gjPTCuatZpU55eUH?

[akrabat]

A little bit more investigation shows that if I do a pre-flight OPTIONS call, then API Gateway will respond with a reflection of what I send:

$ curl -i -X OPTIONS -H "Access-Control-Request-Headers: Content-Type, X-Pingback" https://service.eu.ap…

HTTP/2 200
access-control-allow-credentials: true
access-control-allow-headers: Content-Type, X-Pingback
access-control-allow-methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
access-control-allow-origin: *

Maybe the test suite I'm writing against is wrong to expect Access-Control-Allow-Headers in a "simple" request.

[mhamann]

@akrabat i know this is an old issue, but do you happen to have the api config (swagger) you passed in here?

[akrabat]

I've never used the swagger config, so I would have connected it via wsk api

[rabbah]

@mhamann what's the status on this?

[mhamann]

There should be three states:

• ON: Gateway injects CORS headers
• OFF: Gateway explicitly removes all CORS headers if present
• Passthru: Gateway doesn't inject CORS headers, but allows them to pass through from the backend if present.

I believe this is working correctly, but I'd have to look at the test cases to confirm that.