Setting headers in content by lua file

nic_rioux · 2013-06-07T02:07:38+00:00

Matt,Just curious, what functionality do you get from the Redis call? You said that you are building a cache, but that it's also a redirector. Openresty/ngin...

Setting headers in content by lua file

nic_rioux

Hi! I'm using the following code in a content_by_lua_file :

ngx.header.content_type = 'text/plain'

ngx.say('done')

and it seems the response headers are not containing the content-type set by my lua.

I'm on 1.2.7.8

Am I missing something?

agentzh

Hello!

On Thu, Jun 6, 2013 at 1:07 PM, Nicolas Rioux wrote:
> Hi! I'm using the following code in a content_by_lua_file :
>
> ngx.header.content_type = 'text/plain'
> ngx.say('done')
>
> and it seems the response headers are not containing the content-type set by
> my lua.
>
> I'm on 1.2.7.8
>

Please ensure that your web browser is not caching your response and
it often happens in everyday use. Also, ensure that you've
successfully reload your Nginx's configuration by sending the HUP
signal to Nginx's master process.

To be sure, you can just use command-line http clients like "curl" to
verify the response headers. For example, on my side, for the
following configuration

    location = /t {
        content_by_lua "
            ngx.header.content_type = 'text/plain'
            ngx.say('done')
        ";
    }

After reloading the configuration, I'm getting

    $ curl -i localhost:8080/t
    HTTP/1.1 200 OK
    Server: nginx/1.2.8
    Date: Fri, 07 Jun 2013 03:50:28 GMT
    Content-Type: text/plain
    Transfer-Encoding: chunked
    Connection: keep-alive

    done

We can see that the Content-Type response header is indeed set properly.

Best regards,
-agentzh

anshul

Hi,

I faced the same issue today where in although the rest of the lua code was executing properly but the content type was not set.

Then I 'reload'ed the nginx, and it worked fine

However, when then I 'restart'ed the nginx, it again started giving this problem.

This would continue to happen until I killed all the nginx processes and started it back.

I am not sure if this helps in identifying the cause but I can confirm the issue does exist.

Thanks,

Anshul

On Friday, June 7, 2013 9:21:30 AM UTC+5:30, agentzh wrote:

Hello!

On Thu, Jun 6, 2013 at 1:07 PM, Nicolas Rioux wrote:
> Hi! I'm using the following code in a content_by_lua_file :
>
> ngx.header.content_type = 'text/plain'
> ngx.say('done')
>
> and it seems the response headers are not containing the content-type set by
> my lua.
>
> I'm on 1.2.7.8
>

Please ensure that your web browser is not caching your response and
it often happens in everyday use. Also, ensure that you've
successfully reload your Nginx's configuration by sending the HUP
signal to Nginx's master process.

To be sure, you can just use command-line http clients like "curl" to
verify the response headers. For example, on my side, for the
following configuration

location = /t {
content_by_lua "
ngx.header.content_type = 'text/plain'
ngx.say('done')
";
}

After reloading the configuration, I'm getting

$ curl -i localhost:8080/t
HTTP/1.1 200 OK
Server: nginx/1.2.8
Date: Fri, 07 Jun 2013 03:50:28 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive

done

We can see that the Content-Type response header is indeed set properly.

Best regards,
-agentzh

agentzh

Hello!

On Mon, May 19, 2014 at 3:15 AM,  anshul wrote:
> I faced the same issue today where in although the rest of the lua code was
> executing properly but the content type was not set.
>
> Then I 'reload'ed the nginx, and it worked fine
> However, when then I 'restart'ed the nginx, it again started giving this
> problem.
>
> This would continue to happen until I killed all the nginx processes and
> started it back.
>

Several suggestions:

1. Check your nginx's error log file for any errors or warnings. Also
ensure you use a relatively low "error_log" level like "warn" or even
"info". They can be very helpful when there were some common mistakes
in your Lua code.

2. Please try to create an isolated example that can reproduce this
relatively easily in our boxes.

3. Please enable the nginx debugging logs so that we can see more
details for the guilty requests' handling. See
http://nginx.org/en/docs/debugging_log.html

4. Please always provide the versions of the related software (like
openresty) you're using. If you're not using the latest release of
openresty (1.5.12.1 as of this writing), try upgrading to it.

5. Dynamic tracing tools like systemtap and ktap should be helpful to
trace down your guilty requests in your running nginx processes.

And finally, please subscribe to this list before posting otherwise
your posts require my manual moderation. Thank you for your
cooperation!

Best regards,
-agentzh

anshul

Hi Yichun, will try your suggestions.

Also, after sending the mail the issue was not reproducible by the reload/restart thing, although if you give enough time, the system will land up in the issue which would go away only after a restart.

I tried the logs but they don't have any info at current log level.

Luckily the system is in development mode and I can try all of your suggestions in that.

Let me get back to you with more info/logs.

Regards,

Anshul

On Mon, May 19, 2014 at 11:59 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Mon, May 19, 2014 at 3:15 AM, anshul wrote:
> I faced the same issue today where in although the rest of the lua code was
> executing properly but the content type was not set.
>
> Then I 'reload'ed the nginx, and it worked fine
> However, when then I 'restart'ed the nginx, it again started giving this
> problem.
>
> This would continue to happen until I killed all the nginx processes and
> started it back.
>

Several suggestions:

1. Check your nginx's error log file for any errors or warnings. Also
ensure you use a relatively low "error_log" level like "warn" or even
"info". They can be very helpful when there were some common mistakes
in your Lua code.

2. Please try to create an isolated example that can reproduce this
relatively easily in our boxes.

3. Please enable the nginx debugging logs so that we can see more
details for the guilty requests' handling. See
http://nginx.org/en/docs/debugging_log.html

4. Please always provide the versions of the related software (like
openresty) you're using. If you're not using the latest release of
openresty (1.5.12.1 as of this writing), try upgrading to it.

5. Dynamic tracing tools like systemtap and ktap should be helpful to
trace down your guilty requests in your running nginx processes.

And finally, please subscribe to this list before posting otherwise
your posts require my manual moderation. Thank you for your
cooperation!

Best regards,
-agentzh.

anshulagrawal

Hi Yichun,

I could try with debug build now. Not seeing anything useful in the logs. Attaching the logs for two exact requests made through curl.

I am using nginx_1.5.11.1 with ngx_pagespeed

The concerned location block looks like this:

location / {

content_by_lua '

ngx.header.content_type = "text/plain"

ngx.say("RECEIVED REQUEST")

ngx.say("================")

ngx.say("")

ngx.say(ngx.req.raw_header())

ngx.req.read_body()

if ngx.req.get_body_data() then

ngx.say(ngx.req.get_body_data())

end

ngx.say("MODIFIED HEADERS")

ngx.say("================")

ngx.say("")

local h = ngx.req.get_headers()

for k, v in pairs(h) do

ngx.say(k,": ",v)

end

ngx.say("Start Time: ",ngx.req.start_time(), " Seconds")

ngx.say("End Time: ",ngx.now(), " Seconds")

}

Behaviour is same as earlier. I will get text/plain initially and after some time the server will start responding with the default application/octet-stream.

I came across few issues with ngx_pagespeed ignoring the headers modification as mentioned here:

https://github.com/openresty/headers-more-nginx-module/issues/21

https://github.com/pagespeed/ngx_pagespeed/issues/612

Do you think I might be hitting the same bug?

Regards,

Anshul

On Tuesday, 20 May 2014 00:16:14 UTC+5:30, Anshul wrote:

Hi Yichun, will try your suggestions.

Also, after sending the mail the issue was not reproducible by the reload/restart thing, although if you give enough time, the system will land up in the issue which would go away only after a restart.

I tried the logs but they don't have any info at current log level.

Luckily the system is in development mode and I can try all of your suggestions in that.

Let me get back to you with more info/logs.

Regards,
Anshul
On Mon, May 19, 2014 at 11:59 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:
Hello!

On Mon, May 19, 2014 at 3:15 AM, anshul wrote:
> I faced the same issue today where in although the rest of the lua code was
> executing properly but the content type was not set.
>
> Then I 'reload'ed the nginx, and it worked fine
> However, when then I 'restart'ed the nginx, it again started giving this
> problem.
>
> This would continue to happen until I killed all the nginx processes and
> started it back.
>

Several suggestions:

1. Check your nginx's error log file for any errors or warnings. Also
ensure you use a relatively low "error_log" level like "warn" or even
"info". They can be very helpful when there were some common mistakes
in your Lua code.

2. Please try to create an isolated example that can reproduce this
relatively easily in our boxes.

3. Please enable the nginx debugging logs so that we can see more
details for the guilty requests' handling. See
http://nginx.org/en/docs/debugging_log.html

4. Please always provide the versions of the related software (like
openresty) you're using. If you're not using the latest release of
openresty (1.5.12.1 as of this writing), try upgrading to it.

5. Dynamic tracing tools like systemtap and ktap should be helpful to
trace down your guilty requests in your running nginx processes.

And finally, please subscribe to this list before posting otherwise
your posts require my manual moderation. Thank you for your
cooperation!

Best regards,
-agentzhput filter "/?" 2014/08/14 05:08:52 [debug] 11637#0: *8 http copy filter: "/?" 2014/08/14 05:08:52 [debug] 11637#0: *8 lua capture body filter, uri "/" 2014/08/14 05:08:52 [debug] 11637#0: *8 image filter 2014/08/14 05:08:52 [debug] 11637#0: *8 xslt filter body 2014/08/14 05:08:52 [debug] 11637#0: *8 http postpone filter "/?" 00007FFF813052F0 2014/08/14 05:08:52 [debug] 11637#0: *8 http chunk: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C1EE0, pos 00007FF29E4C1EE0, size: 162 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2070, pos 00007FF29E4C2070, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C1E60, pos 00007FF29E4C1E60, size: 17 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2200, pos 00007FF29E4C2200, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2178, pos 00007FF29E4C2178, size: 17 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2378, pos 00007FF29E4C2378, size: 3 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C1118, pos 00007FF29E4C1118, size: 1 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2548, pos 00007FF29E4C2548, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2480, pos 00007FF29E4C2480, size: 83 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2718, pos 00007FF29E4C2718, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2690, pos 00007FF29E4C2690, size: 17 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C28A8, pos 00007FF29E4C28A8, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C2820, pos 00007FF29E4C2820, size: 17 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BBCA0, pos 00007FF29E4BBCA0, size: 3 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4C29B0, pos 00007FF29E4C29B0, size: 1 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BBE38, pos 00007FF29E4BBE38, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BBDA8, pos 00007FF29E4BBDA8, size: 25 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BBFC0, pos 00007FF29E4BBFC0, size: 3 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BBF40, pos 00007FF29E4BBF40, size: 12 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BC150, pos 00007FF29E4BC150, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BC0C8, pos 00007FF29E4BC0C8, size: 24 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BC2F0, pos 00007FF29E4BC2F0, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BC258, pos 00007FF29E4BC258, size: 35 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BC490, pos 00007FF29E4BC490, size: 4 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:1 f:0 00007FF29E4BC3F8, pos 00007FF29E4BC3F8, size: 33 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write old buf t:0 f:0 0000000000000000, pos 00007FF29CE16218, size: 2 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 write new buf t:0 f:0 0000000000000000, pos 00007FF29CE16212, size: 5 file: 0, size: 0 2014/08/14 05:08:52 [debug] 11637#0: *8 http write filter: l:1 f:0 s:518 2014/08/14 05:08:52 [debug] 11637#0: *8 http write filter limit 0 2014/08/14 05:08:52 [debug] 11637#0: *8 writev: 518 2014/08/14 05:08:52 [debug] 11637#0: *8 http write filter 0000000000000000 2014/08/14 05:08:52 [debug] 11637#0: *8 http copy filter: 0 "/?" 2014/08/14 05:08:52 [debug] 11637#0: *8 http finalize request: 0, "/?" a:1, c:1 2014/08/14 05:08:52 [debug] 11637#0: *8 set http keepalive handler 2014/08/14 05:08:52 [debug] 11637#0: *8 http close request 2014/08/14 05:08:52 [debug] 11637#0: *8 lua request cleanup: forcible=0 2014/08/14 05:08:52 [debug] 11637#0: *8 http log handler 2014/08/14 05:08:52 [debug] 11637#0: *8 free: 00007FF29E4C0120, unused: 7 2014/08/14 05:08:52 [debug] 11637#0: *8 free: 00007FF29E4C1A30, unused: 8 2014/08/14 05:08:52 [debug] 11637#0: *8 free: 00007FF29E4BBC80, unused: 1547 2014/08/14 05:08:52 [debug] 11637#0: *8 free: 00007FF29E4BF6D0 2014/08/14 05:08:52 [debug] 11637#0: *8 hc free: 0000000000000000 0 2014/08/14 05:08:52 [debug] 11637#0: *8 hc busy: 0000000000000000 0 2014/08/14 05:08:52 [debug] 11637#0: *8 tcp_nodelay 2014/08/14 05:08:52 [debug] 11637#0: *8 reusable connection: 1 2014/08/14 05:08:52 [debug] 11637#0: *8 event timer add: 3: 65000:1407992997996 2014/08/14 05:08:52 [debug] 11637#0: *8 post event 00007FF29E416E38 2014/08/14 05:08:52 [debug] 11637#0: *8 delete posted event 00007FF29E416E38 2014/08/14 05:08:52 [debug] 11637#0: *8 http keepalive handler 2014/08/14 05:08:52 [debug] 11637#0: *8 malloc: 00007FF29E4BF6D0:1024 2014/08/14 05:08:52 [debug] 11637#0: *8 recv: fd:3 -1 of 1024 2014/08/14 05:08:52 [debug] 11637#0: *8 recv() not ready (11: Resource temporarily unavailable) 2014/08/14 05:08:52 [debug] 11637#0: *8 free: 00007FF29E4BF6D0 2014/08/14 05:08:53 [debug] 11637#0: *8 http keepalive handler 2014/08/14 05:08:53 [debug] 11637#0: *8 malloc: 00007FF29E4BF6D0:1024 2014/08/14 05:08:53 [debug] 11637#0: *8 recv: fd:3 0 of 1024 2014/08/14 05:08:53 [info] 11637#0: *8 client 106.51.241.238 closed keepalive connection 2014/08/14 05:08:53 [debug] 11637#0: *8 close http connection: 3 2014/08/14 05:08:53 [debug] 11637#0: *8 event timer del: 3: 1407992997996 2014/08/14 05:08:53 [debug] 11637#0: *8 reusable connection: 0 2014/08/14 05:08:53 [debug] 11637#0: *8 free: 00007FF29E4BF6D0 2014/08/14 05:08:53 [debug] 11637#0: *8 free: 00007FF29E4C3DA0, unused: 0 2014/08/14 05:08:53 [debug] 11637#0: *8 free: 00007FF29E4BF520, unused: 104
agentzh
Hello!

On Thu, Aug 14, 2014 at 12:11 AM, Anshul Agrawal wrote:
> I could try with debug build now. Not seeing anything useful in the logs.
> Attaching the logs for two exact requests made through curl.
>
> I am using nginx_1.5.11.1 with ngx_pagespeed
>

Can you reproduce the issue *without* ngx_pagespeed in your nginx or
openresty build? That 3rd-party module is not maintained by OpenResty
authors and I'm not interested in investigating issues introduced by
that module unless someone explicitly tells me what *I* am doing wrong
(if I am) :)

Regards,
-agentzh
anshulagrawal

Ok. Will build nginx without pagespeed module and give it a shot.

Will post my findings next week some time.

Regards

On Fri, Aug 15, 2014 at 4:15 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:
Hello!

On Thu, Aug 14, 2014 at 12:11 AM, Anshul Agrawal wrote:
> I could try with debug build now. Not seeing anything useful in the logs.
> Attaching the logs for two exact requests made through curl.
>
> I am using nginx_1.5.11.1 with ngx_pagespeed
>

Can you reproduce the issue *without* ngx_pagespeed in your nginx or
openresty build? That 3rd-party module is not maintained by OpenResty
authors and I'm not interested in investigating issues introduced by
that module unless someone explicitly tells me what *I* am doing wrong
(if I am) :)

Regards,
-agentzh

--

.

anshulagrawal

Hi Yichun,
Still no luck.

To note, my earlier build were made using this forked project I have on github:
https://github.com/designgrill/omnibus-nginx

This is what I tried this week:
Turning Pagespeed off using config
Building without ngx_pagespeed (This rules out any issue with pagespeed inclusion)
Building 1.5.11.1 fresh from downloading source directly from openresty.org

Building the latest 1.7.2.1 fresh from openresty.org
More about the issue:
The issue is happening only when setting headers using ngx.header. If I use add_header call, it works fine.

Issue doesn't crop up immediately after a nginx restart. It takes some time may be because processing other requests during that time causes the issue to show up.
Response Headers of all the proxy responses are respected

Test Lua Code:
location /lua_content_header {
content_by_lua "
ngx.header.content_type = 'text/plain'
ngx.say('Hello,world!')

";
}

:(

Regards,
Anshul

On Fri, Aug 15, 2014 at 5:02 AM, Anshul Agrawal <anshul...@gmail.com> wrote:

Ok. Will build nginx without pagespeed module and give it a shot.

Will post my findings next week some time.

Regards

On Fri, Aug 15, 2014 at 4:15 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:
Hello!

On Thu, Aug 14, 2014 at 12:11 AM, Anshul Agrawal wrote:
> I could try with debug build now. Not seeing anything useful in the logs.
> Attaching the logs for two exact requests made through curl.
>
> I am using nginx_1.5.11.1 with ngx_pagespeed
>

Can you reproduce the issue *without* ngx_pagespeed in your nginx or
openresty build? That 3rd-party module is not maintained by OpenResty
authors and I'm not interested in investigating issues introduced by
that module unless someone explicitly tells me what *I* am doing wrong
(if I am) :)

Regards,
-agentzh

--

.

agentzh

Hello!

On Wed, Aug 20, 2014 at 1:38 AM, Anshul Agrawal wrote:
> Test Lua Code:
> location /lua_content_header {
>     content_by_lua "
>                ngx.header.content_type = 'text/plain'
>                ngx.say('Hello,world!')
>   ";
> }
>

Unfortunately I cannot reproduce any issues by loading this location
with simple test requests on Linux x86_64.

You'll have to create standalone, complete, and minimal example
(nginx.conf + Lua code +  experiment instructions and results) that
can be used to reproduce the issue relatively reliably in others'
boxes (in particular, in my box).

I cannot really help you debug any issues I can never see on my side. Sorry.

Regards,
-agentzh

anshulagrawal

I understand. Unfortunately I am unable to get exact steps to reproduce the issue. Every iteration requires me to wait for few hours (may be a day) to see the issue crop up.

For now I am settled with using default_type in those location blocks as no other custom headers were required.

I hope its just me. Thanks for all your help and efforts.

On Thu, Aug 21, 2014 at 5:16 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Wed, Aug 20, 2014 at 1:38 AM, Anshul Agrawal wrote:
> Test Lua Code:
> location /lua_content_header {
> content_by_lua "
> ngx.header.content_type = 'text/plain'
> ngx.say('Hello,world!')
> ";
> }
>

Unfortunately I cannot reproduce any issues by loading this location
with simple test requests on Linux x86_64.

You'll have to create standalone, complete, and minimal example
(nginx.conf + Lua code + experiment instructions and results) that
can be used to reproduce the issue relatively reliably in others'
boxes (in particular, in my box).

I cannot really help you debug any issues I can never see on my side. Sorry.

Regards,
-agentzh.

anshulagrawal

Hi,

Finally. I was able to get a 100% reproduction case while working on something else and was able to figure out the issue.

I was making a mistake in a util function I wrote to return the response obtained from a sub request (made using location.capture) back to the client.

function utils.return_subresponse(response)

ngx.status = response.status

ngx.header = response.header

ngx.print(response.body)

ngx.exit(ngx.HTTP_OK)

end

The ngx.header assignment above was wrong. The effect of it lasts till nginx restart and you won't be able to set any headers through lua till then.

Fixed version:

function utils.return_subresponse(response)

ngx.status = response.status

for header_key, header_value in pairs(response.header) do

ngx.header[header_key] = header_value

end

ngx.print(response.body)

ngx.exit(ngx.HTTP_OK)

end

Hope it helps someone who is making similar mistake.

Regards,

Anshul

On Thu, Aug 21, 2014 at 10:21 AM, Anshul Agrawal <anshul...@gmail.com> wrote:

I understand. Unfortunately I am unable to get exact steps to reproduce the issue. Every iteration requires me to wait for few hours (may be a day) to see the issue crop up.

For now I am settled with using default_type in those location blocks as no other custom headers were required.

I hope its just me. Thanks for all your help and efforts.

On Thu, Aug 21, 2014 at 5:16 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Wed, Aug 20, 2014 at 1:38 AM, Anshul Agrawal wrote:
> Test Lua Code:
> location /lua_content_header {
> content_by_lua "
> ngx.header.content_type = 'text/plain'
> ngx.say('Hello,world!')
> ";
> }
>

Unfortunately I cannot reproduce any issues by loading this location
with simple test requests on Linux x86_64.

You'll have to create standalone, complete, and minimal example
(nginx.conf + Lua code + experiment instructions and results) that
can be used to reproduce the issue relatively reliably in others'
boxes (in particular, in my box).

I cannot really help you debug any issues I can never see on my side. Sorry.

Regards,
-agentzh.