Open akrabat opened 6 years ago
side note but why are there two x-request-id
fields with values 9e54ef0ebeafdcfd2ea43d6806820587
and nluhqvi9P9YoSXB8gjPTCuatZpU55eUH
?
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.
@akrabat i know this is an old issue, but do you happen to have the api config (swagger) you passed in here?
I've never used the swagger config, so I would have connected it via wsk api
@mhamann what's the status on this?
There should be three states:
I believe this is working correctly, but I'd have to look at the test cases to confirm that.
Given an action that looks like this:
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:
Headers in the API Gateway response:
As you can see, the
Access-Control-Allow-Headers
header that's in the web action response is missing from the API Gateway response.