When examining ngx.header.content_length of a RESPONSE, we notice this field is nil ONLY when the response content-type is text/html.
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: text/plain, application/json, application/xml. Only for text/html is it nil.
So I’m thinking maybe something in Kong, ngx, openresty is stripping it? But only for this specific content-type value?
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.
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.
.