lua-nginx-module
lua-nginx-module copied to clipboard
[Bug] response header "Transfer-Encoding" set by user doesn't work and cause strange behavior
To reproduce:
location = /t {
default_type 'text/test';
access_by_lua_block {
ngx.header["Transfer-Encoding"] = "gzip"
ngx.say('what')
}
}
(I don't expect the gzip to work, because how could it work if gzip is not enabled)
You will see a response header like:
Transfer-Encoding: chunked, gzip
(Notice that chunked goes first)
And if you try "chunked" you will get "chunked, chunked".
Guess this is related to the special handling when Content-Length is not set.
location = /t {
default_type 'text/test';
access_by_lua_block {
ngx.header["Transfer-Encoding"] = "chunked"
ngx.header["Content-Length"] = 4
ngx.print('what')
}
}
This may be proof of my opinion. It responds with the correct chunked header.
I can try to fix that myself, but could anyone suggest to me where to find the logic of handling nil Content-Length?
lua-nginx-module/src/ngx_http_lua_headers_in.c seems related though.
https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.1
A sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer coding other than chunked is applied to a request payload body, the sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than chunked is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection.
Is there a need to change the Transfer-Encoding?
Is there a need to change the Transfer-Encoding?
I am not sure either. I was only forwarding the user's issue, and they did not state the background.
Is there a need to change the Transfer-Encoding?
And maybe if we decide not to support this, should we mention it in the documentation?