Response content-length header stripped when content-type is "text/html"


#1

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?

Any thoughts?

Edit: This is in Kong 1.0


#2

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.


#3

Hi,

I have created a Github issue to investigate this: https://github.com/Kong/kong/issues/4306


#4

This has been solved, bit of a false alarm here. Sorry folks I am just a bad coder :laughing: . @Ross_Sbriscia we can close this question and mark as answered.


#5

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.


#6

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 :laughing: .

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.