ngx.header.content_length of a RESPONSE, we notice this field is
nil ONLY when the response
In all cases, the
Content-Length header is being explicitly set on the response. And
ngx.header.content_length is accurate when the
Content-Type is any of the following:
application/xml. Only for
text/html is it
So I’m thinking maybe something in Kong, ngx, openresty is stripping it? But only for this specific
Edit: This is in Kong 1.0
Sat and looked at this with Ross for a few hours today stumped as to why one of our plugins was seemingly acting bugged even while the high level logic looked fine:
Of course text/html should never really be seen as an API response content-type, but still the fact either Kong/OpenResty/Nginx does not populate the content-length in the ngx response headers context in this scenario is weird because we echo it and verified its certainly set when hitting it directly.
I have created a Github issue to investigate this: https://github.com/Kong/kong/issues/4306
This has been solved, bit of a false alarm here. Sorry folks I am just a bad coder . @Ross_Sbriscia we can close this question and mark as answered.
Still somewhat puzzled why it happened in a first place. Would love to see all the request and response headers. Why the ngx.header[“Content-Length”] gets cleared? Does some other plugin do it? Is there some other things in response that makes it turn to chunked (is that what is happening?). But sure I am glad there was a workaround.
Well Mr. Bungle it really was nothing out of the ordinary in the response headers that I recalled, nothing around chunked/encoding stuffs. No other plugins were on it that I know of for those calls. It was just dummy data in the http body and text/html as content-type that did it for us with content-length set to the byte size of dummy data. If I can get Ross to post the raw headers the full response had coming back from the echo webserver I will, but my guess is he won’t want to revisit this as I think he spent like 6-8 hours around this issue in total back when he was pulling his hair out wondering why either his test-suite(we wrote a plugin validation test suite recently to catch plugins breaking in functionality from version to version) or why the response-size-limiting plugin we had was wrong .
I was scratching my head thinking why the plugin was wrong then I remembered I had been using pure ngx stuff, then quickly changed it to use pdk at one point, saw mem leaks, tibo fixed mem leaks but during that time i hastily reverted back to pure ngx(and did so wrongly). So I think was all just my goof of choosing the wrong way to get that header, In the context of the header phase on the response, I suppose ngx.header[“Content-Length”] still should represent the request size eh? So maybe its interesting that the content-type on the response changing from say application/xml to text/html caused it to nil out was interesting but ultimately had nothing to do with what was our actual problem.