Headers not being sent

[ljmc2000]

Description
So this is a little odd. when I say
return response.Response(ctx, response_data="",headers{"Content-Type":"application/xml"})
the data is passed down through the stack and everything is hunky dorey. Everyone can see my outdated tastes in information interchange. However, if I try to set a header with no default value, such as Set-Cookie
return response.Response(ctx, response_data="",headers{"Set-Cookie": "Cookies=Delicious!"})
it gets lost in the mail and no browser will ever know of my passion for sweet chocolate chips :'(

Steps to reproduce the issue:

1. create a default fn application with python runtime
2. scroll down to the line headers{"Content-Type":"application/json"} and add a new header such as set cookie. the value doesn't matter. we're displaying absence here
3. build and run curl -i against the endpoint. your new header will be absent

Describe the results you received:
headers that do not override another header vanish into the ether

Describe the results you expected:
headers are passed down through the layers and the browser shall know of my love of cookies.

Additional information you deem important (e.g. issue happens only occasionally):
overriding the fn-call-id header results in the fn-call-id header being sent twice. once with your override, once the original.

HTTP/1.1 200 OK
Content-Type: application/xml
Fn-Call-Id: 01DCMV614BNG8G00GZJ000001D
Fn-Call-Id: probably should not be overrideable
Date: Wed, 05 Jun 2019 22:12:07 GMT
Content-Length: 26

when running the fn server with the flag --log-level DEBUG your headers appear in the output:

resp="&{200 OK 200 HTTP/1.1 1 1 map[Content-Type:[application/xml] Fn-Call-Id:[probably should not be overrideable] Set-Cookie:[Cookies=Delicious] Age:[12] Fn-Fdk-Version:[0.1.5] Content-Length:[26] Connection:[keep-alive] Keep-Alive:[75]] 0xc420150e00 26 [] false false map[] 0xc420277100 <nil>}"

[rdallman]

@fmtovland thanks for the laughs (though I would agree, the issue isn't funny!). this is odd, and oddly there is a test for this kind of thing too. I will be able to dig in friday if nobody beats me to this, and add a test for the double header, which should get chained as a list rather than be 2 separate items (weird). thank you for the debug report.

one more piece of information that might be useful (I will debug as well), would be if this is an http trigger or if this is from just invoking? i could see maybe how we're making a mistake somewhere in encapsulating the headers and so on (though, there is a test) and getting it out of the function but not passing it up out of the http trigger.

[denismakogon]

The response you've posted above is what FDK provides:

resp="&{200 OK 200 HTTP/1.1 1 1 map[Content-Type:[application/xml] Fn-Call-Id:[probably should not be overrideable] Set-Cookie:[Cookies=Delicious] Age:[12] Fn-Fdk-Version:[0.1.5] Content-Length:[26] Connection:[keep-alive] Keep-Alive:[75]] 0xc420150e00 26 [] false false map[] 0xc420277100 <nil>}"

So, answering the first question. As you can see the cookie header is there. Meaning that somewhat happens while Fn processes FDK response.

[ljmc2000]

That information was from curl so it came from a http trigger.

[ljmc2000]

@rdallman I ran the same test on the previous version of the FDK (the one with the wacky double content type glitch). The problem was not present there. If I had to guess I'd say the problem was introduced when you fixed the double content-type glitch.

Here's the real kicker. if you prefix your header name with "Fn-Http-H-" then the header shows up as expected, sans the "Fn-http-H" prefix. I only found this out by reading through the code. is there a reason for this behaviour? does it help fix the double content-type glitch? Is this behaviour documented somewhere and I'm too lazy to find it?

If you think it should be changed the culprit is probably fdk/headers.py line 29. If not, let me know and I'll close the issue. I'd make the change myself, and make a pull request but I have no idea how you guys test the fdk, and can't figure it out. Sorry to be of insufficient help.

[rdallman]

Thanks for following up with the details, I've repro'd it, as well, and see the same behavior - I'm hoping to have a fix in this week, with some more tests - one of the issues with the tests the way they are is that they aren't testing the same code path as a 'real' execution, and I was hoping to fix this all in one fell swoop but it's taking longer than I'd like.

wrt the prefix itself, it's poorly documented here: https://github.com/fnproject/docs/blob/master/fn/develop/fn-format.md - I'm gonna try to add more details from the internal doc to this, as well. the prefix is supposed to be that way for http triggers (not invoke), where the prefix gets stripped by the gateway (in this case, fn itself), and the fdk is responsible for encapsulating the headers from the user with that prefix when they come out of the fdk. sorry that this is not better documented, will try to fix this up.

[rdallman]

i'm getting double content type again now, so gonna look into this some more, sorry