Xumin

https://www.nginx.com/resources/wiki/start/topics/examples/headers_management/

> Note that the [ngx.var.HEADER](https://github.com/openresty/lua-nginx-module#ngxvarvariable) API call, which uses core [$http_HEADER](http://nginx.org/en/docs/http/ngx_http_core_module.html#var_http_) variables, may be more preferable for reading individual request headers. Yes, it solves some of the problems. But `$http_HEADER`...

It looks like a hack and relies on an undocumented implementation detail of `resty.http`. Anyone could suggest a better idea?

Also, I am not sure if this is permitted by the RFC.

```lua 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...

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](https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_headers_in.c#L636) 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...

> 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?

> It'd be really beneficial if we get the START_TIME and the END_TIME of that event Let's do it in another PR.