Setting headers in content by lua file

[Nicolas 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

[ans...@designgrill.com]

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

[Yichun Zhang (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

Best regards,
-agentzh

--
You received this message because you are subscribed to a topic in the Google Groups "openresty-en" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openresty-en/dJTUBy68ryk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anshul Agrawal]

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

[Yichun Zhang (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

[Anshul Agrawal]

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

Will post my findings next week some time.

Regards

--

You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.

[Anshul Agrawal]

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:

1. Turning Pagespeed off using config
2. Building without ngx_pagespeed (This rules out any issue with pagespeed inclusion)
3. Building 1.5.11.1 fresh from downloading source directly from openresty.org
4. Building the latest 1.7.2.1 fresh from openresty.org

More about the issue:

1. The issue is happening only when setting headers using ngx.header. If I use add_header call, it works fine.
   
2. 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.
3. 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

[Yichun Zhang (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

[Anshul Agrawal]

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.

Regards,
-agentzh

[Anshul Agrawal]

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