Quitting a Request when a Subrequest is started.

[openresty]

Quitting a Request when a Subrequest is started.

[agentzh]

On Mon, Jun 6, 2011 at 9:13 PM, moodydeath
[email protected]
wrote:

The baseline for the explanation would be: I want to catch a request,
change it, do a subrequest with the information gathered and then
output the information received by the subrequest (i don't want the
original request to be executed at all!)?

Does ngx.exec() achieve what you want?

The ngx.exec() function does an internal redirection to the new
location that you specify and the old main request get substituted by
the new request. The new request is not really a "subrequest" though,
since it becomes the new "main request".

Please consult the ngx_lua documentation for more details :)

-agentzh

Somehow yes, but the problem with ngx.exec is, that i have no control of the response-headers there, do i?

Assuming ngx.header is implemented, that we are able to get response headers, is there the possibility to be able to customize those after ngx.exec()?

Besides this, there is no way to customize the request body? ngx.location.capture can have an optional parameter for that, but ngx.exec() will take what is in ngx.var.request_body? (or do i have full access to this ngx.var? means r/w?)

[agentzh]

On Tue, Jun 7, 2011 at 12:30 AM, moodydeath
[email protected]
wrote:

Somehow yes, but the problem with ngx.exec is, that i have no control of the response-headers there, do i?

This should be done via output header filters. Can ngx_headers_more
help you here?

Assuming ngx.header is implemented, that we are able to get response headers, is there the possibility to be able to customize those after ngx.exec()?

No, it's irrelevant.

Besides this, there is no way to customize the request body? ngx.location.capture can have an
optional parameter for that, but ngx.exec() will take what is in ngx.var.request_body? (or do i have full access to this ngx.var? means r/w?)

Well, it can be done on the C level, so we could add a "body" option
to ngx.exec() or just expose ngx.req.set_body() method so that you can
call that to rewrite the request body just before invoking ngx.exec().

I'm wondering what is the real world use case for this?

Regards,
-agentzh

I'm trying to create some kind of application firewall plugin for nginx on top of the lua-language... Don't worry about performance or solutions that would work better - the thing is, that in the end everything should only depend on the lua-nginx-module. And for now it should be only some kind of proof-of-concept project with the attention on reliability

For now, everything is just fine, but the problem (which is the worst) is, that we can't stop the original request or better replace it with the content/headers/etc. from the subrequest.

The processing would be:

• Fetching all the request information (req-body, req-headers, some information from the ngx.vars)
• Looking, if there's any suspicious and eventually remove/add some things (new headers, different req-body, etc.)
• Only after that the request should be hit (currently with the subrequest-solution)
• Now all the information should be analyzed (res.body, res.headers do a good job here) and (again) there should be the possibility of changing response headers, the body, etc. and only then the response should be sent back to the client.

I understand that this (i mean the last part) is done via output-filters... but everything would work fine as it is, if there is the possibility to stop the original plain request from being processed...

As a workaround i tried to ngx.exec() to an empty location at the end of the script in my first post... But ... workaround (which i think does not solve all problems as well) :-)

[agentzh]

On Tue, Jun 7, 2011 at 4:19 PM, moodydeath
[email protected]
wrote:

As a workaround i tried to ngx.exec() to an empty location at the end of the script in my first post... But ... workaround (which i think does not solve all problems as well) :-)

Are you using rewrite_by_lua or access_by_lua? If yes, you can
short-circuit the current request by doing ngx.exit(0). Will that work
for you?

If you're using content_by_lua, then there's no need to do such exiting anyway.

Regards,
-agentzh

Using rewrite_by_lua_file for this.

ngx.exit(0) at the end of my testscript does not work - will end in timeouts when trying to access sites.

ngx.exit(200) works (better), though some applications refuse to work 100% correct then - e.g. the ajax-stuff in the newest phpmyadmin, etc..

I can't imagine, where the fault for this behaviour is :-(

[agentzh]

On Tue, Jun 7, 2011 at 7:12 PM, moodydeath
[email protected]
wrote:

Using rewrite_by_lua_file for this.

ngx.exit(0) at the end of my testscript does not work - will end in timeouts when trying to access sites.

ngx.exit(200) works (better), though some applications refuse to work 100% correct then - e.g. the ajax-stuff in the newest phpmyadmin, etc..

Could you give me a minimized version of your test script to reproduce
this problem? If ngx.exit() does not work in this context, then there
must be a bug :)

Thanks!
-agentzh

[agentzh]

On Tue, Jun 7, 2011 at 10:08 PM, agentzh [email protected] wrote:

ngx.exit(200) works (better), though some applications refuse to work 100% correct then - e.g. the ajax-stuff in the newest phpmyadmin, etc..

Could you give me a minimized version of your test script to reproduce
this problem? If ngx.exit() does not work in this context, then there
must be a bug :)

Okay...my fault...I've reproduced this issue for rewrite_by_lua* on my
side and fixed it in the new "exit-fixes" branch in the git repos.
Could you try it out?

According to the documentation of ngx_lua, ngx.exit(0) will only quit
the current rewrite phase handler while ngx.exit(status) where status

= 200 and status < 300 will quit the current request altogether and
skip all the subsequent phases, which is exactly what you want.

Use of ngx.exit() is still broken in the same way for access_by_lua*
even in the "exit-fixes" branch, I'll fix that later there.

Thanks!
-agentzh

[agentzh]

On Tue, Jun 7, 2011 at 11:21 PM, agentzh [email protected] wrote:

Use of ngx.exit() is still broken in the same way for access_by_lua*
even in the "exit-fixes" branch, I'll fix that later there.

I've just fixed ngx.exit() for access_by_lua* in the "exit-fixes"
branch as well ;)

Thanks!
-agentzh

Hi, sorry for the deleay ... but i tested it and everything works fine, now! :-)

I can confirm, that this code will work and output the page generated by the subrquest (ok, there are some more lines for POST-Data, etc. but generally this works)

if ngx.is_subrequest == false then

    res = ngx.location.capture(ngx.var.request_uri)

    for i,j in pairs(res.header) do
        ngx.header[i] = j
    end

     ngx.print(res.body)

    ---ngx.flush()
    ---ngx.eof()
    ngx.exit(res.status)

end

ngx.eof() or ngx.flush() won't work here, but this is expected. Can you confirm, that - with this method - the original request will never hit nginx and only the HTTP-request for the subrequest will be performed?

By the way, there's still a small problem. If a subrequest returns a 302-Error that says the page has moved there will be a location-header that contains the new url for automatic forwarding... this works fine, but with the subrequest, the location-entry will contain "localhost" as hostname in the path for the new url... :( - i think that this has something to do with the fact, that the subrequest is put there as some kind of "local" internal request?

[agentzh]

On Fri, Jun 10, 2011 at 9:36 PM, moodydeath
[email protected]
wrote:

Hi, sorry for the deleay ... but i tested it and everything works fine, now! :-)

I can confirm, that this code will work and output the page generated by the subrquest (ok, there are some more lines for POST-Data, etc. but generally this works)

Yay! I'll merge the "exit-fixes" branch back to master when I go back
to Beijing this weekend or so.

ngx.eof() or ngx.flush() won't work here, but this is expected. Can you confirm, that - with this method - the original request will never hit nginx and only the HTTP-request for the subrequest will be performed?

Your rewrite_by_lua_file directive always runs at the rewrite phase of
the original request anyway. So it's meaningless to say "the original
request will never hit nginx". Using ngx.exit() there just skips the
subsequent access and content phases of the "original request"
altogether. Therefore, we can say that the original request will never
hit its content phase handler.

By the way, there's still a small problem. If a subrequest returns a 302-Error that says the page has moved there will be a location-header that contains the new url for automatic forwarding... this works fine, but with the subrequest, the location-entry will contain "localhost" as hostname in the path for the new url... :( - i think that this has something to do with the fact, that the subrequest is put there as some kind of "local" internal request?

That's because your nginx virtual server is configured by the name
"localhost" or your request is performed by the request header "Host:
localhost". Alternatively, you can explicitly specify an absolute url
as the value of the "Location" response header.

Regards,
-agentzh

Found the thing about the localhost-problem some minutes ago, too :-) ... Thanks!

[agentzh]

On Fri, Jun 10, 2011 at 10:06 PM, agentzh [email protected] wrote:

Yay! I'll merge the "exit-fixes" branch back to master when I go back
to Beijing this weekend or so.

I‘ve just merged the exit-fixes branch to master and tagged the
v0.1.6rc11 release.

Enjoy!
-agentzh

Really great, thank you! :-)

There are two small (?) flaws of which i don't know, if they belong to this issue or another (so i'll just post it here and don't open another one):

(1): index index.html index.htm index.php; <-- this would be in the main location / for index-files

When a request is set to http://domain.tld/index.php or http://domain.tld/index.htm(l) everything works correct

When a request is done @ http://domain.tld/phpbb/ should be a index.php accessed it will return the correct page, but the request will last for a long time and after the normal page the response-headers will be in the output.
When requesting http://domain.tld/ and there should be a index.htm(l) it's the same. The page needs ~1 minute to load and after the normal content the response headers will be shown: http://moodydeath.de/pictures/welcome.png

When requesting http://domain.tld/phpbb and there should be a index.php -> a 301 error is returned

This behaviour is only when the lua-script is activated, so i can exclude that the fault is in a misconfigured nginx.conf (like i had before :-) ) ... Is there something missing in my script that should handle this?

if ngx.is_subrequest == false then

    function set_request_method()
        local val = ngx.var.request_method
        if val == "GET" then
            return ngx.HTTP_GET
        elseif val == "HEAD" then
            return ngx.HTTP_HEAD
        elseif val ==  "PUT" then
            return ngx.HTTP_PUT
        elseif val == "POST" then
            return ngx.HTTP_POST
        elseif val == "DELETE" then
            return ngx.HTTP_DELETE
        end
    end

        res = ngx.location.capture(ngx.var.request_uri, { method = set_request_method(), body = ngx.var.request_body})

        for i,j in pairs(res.header) do ngx.header[i] = j end

        ngx.print(res.body)
        ngx.exit(res.status)

end

The second thing is - and i have to investigate a bit more about this today and tomorrow - that with specific applications like Wordpress or phpMyAdmin the login does not work when the script is activated because they are using a 302-redirect in the login-scripts which - somehow - do not work when using my script... Debug-Messages and Tamper show that request- and response-information are actually sent in correct form... But i will have to have a closer look on it!

Btw. it's no big deal, but it does not really look pretty with the wrapper for the request-methods - but is there another way for ngx.var.request_method and what ngx.location.capture needs as method?

[agentzh]

On Sun, Jun 12, 2011 at 7:27 PM, moodydeath
[email protected]
wrote:

Really great, thank you! :-)

There are two small (?) flaws of which i don't know, if they belong to this issue or another (so i'll just post it here and don't open another one):

(1): index  index.html index.htm index.php; <-- this would be in the main location / for index-files

When a request is set to http://domain.tld/index.php or http://domain.tld/index.htm(l) everything works correct

For now, ngx.location.capture cannot work with locations with internal
redirections because the ngx_http_internal_redirect function clears
all those modules' ctx objects. The "index" directive effectively
performs an internal redirection.

It can be fixed by modifying ngx_lua's output filter to inspect the
parent request's ngx_lua ctx to see if it's one of its capturing
subrequest.

When a request is done @ http://domain.tld/phpbb/ should be a index.php accessed it will return the correct page, but the request will last for a long time

Yeah, the ngx_lua ctx is cleared so the state machine does not
function at all, hence the hang.

I hope I can find some time to fix this these days. I've been
extremely busy with other stuffs :(

The second thing is - and i have to investigate a bit more about this today and tomorrow - that with specific applications like Wordpress or phpMyAdmin the login does not work when the script is activated because they are using a 302-redirect in the login-scripts which - somehow - do not work when using my script... Debug-Messages and Tamper show that request- and response-information are actually sent in correct form... But i will have to have a closer look on it!

Good luck with this one!

Thanks!
-agentzh

[agentzh]

On Tue, Jun 14, 2011 at 10:51 AM, agentzh [email protected] wrote:

For now, ngx.location.capture cannot work with locations with internal
redirections because the ngx_http_internal_redirect function clears
all those modules' ctx objects. The "index" directive effectively
performs an internal redirection.

It can be fixed by modifying ngx_lua's output filter to inspect the
parent request's ngx_lua ctx to see if it's one of its capturing
subrequest.

I've just fixed this issue in my local working tree. I'll commit my
fixes to the devel branch for you to try once my test suite completes
running ;)

Thanks!
-agentzh

[agentzh]

On Wed, Jun 15, 2011 at 4:14 PM, agentzh [email protected] wrote:

I've just fixed this issue in my local working tree. I'll commit my
fixes to the devel branch for you to try once my test suite completes
running ;)

Already committed to both the devel and master branches. Could you
give it a wheel? ;)

Thanks!
-agentzh

Works perfect for requests to an url that ends with a "/" like http://localhost/foo/
If the "/" is missing, i'll get a 301 Moved Permanently. Except for the main location.

And i think the problem with the logins that are not working (on wordpress, phpmyadmin, etc.) the issue is in ngx.location.capture not sending the body-data at the moment.

Some things that could confirm my assumption:

using as rewrite_by_lua_file:

if ngx.is_subrequest == false then    
    res = ngx.location.capture("/info.php", {method = ngx.HTTP_POST, body = "foo"})
    for i,j in pairs(res.header) do ngx.header[i] = j end
    ngx.print(res.body)
    ngx.exit(res.status)
end

/info.php is just a small phpscript which will echo the request_body in output...
when the lua-script is deactivated, and i hit a post-request by curl including a request_body everything works correct and i get the output.

When the lua-code is acitve, i get a timeout from nginx (504) at the client and the error.log contains:

2011/06/15 15:06:42 [error] 26525#0: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.100.20.192, server: 10.20.10.210, request: "POST /info.php HTTP/1.1", subrequest: "/info.php", upstream: "fastcgi://127.0.0.1:9000", host: "10.20.10.210:1337"

Somehow the request does not hit the fast-cgi component through the subrequest when using POST and a request_body. It's working without a problem when a request_body is sent to fast-cgi without lua-code in the middle. Normal GET-requests to php-pages work without problems, too.

This happens on nginx 1.0.2 and 1.0.4 with the latest lua-nginx-module from master.

Thanks, moody.

[agentzh]

On Wed, Jun 15, 2011 at 9:33 PM, moodydeath
[email protected]
wrote:

Works perfect for requests to an url that ends with a "/" like http://localhost/foo/
If the "/" is missing, i'll get a 301 Moved Permanently. Except for the main location.

I cannot reproduce it on my side. Could you please submit a failing
test case to the devel branch?

And i think the problem with the logins that are not working (on wordpress, phpmyadmin, etc.) the issue is in ngx.location.capture not sending the body-data at the moment.

Some things that could confirm my assumption:

using as rewrite_by_lua_file:

I'll look into this. But it'll also be great if you can code up a
failing test case for it and removing the dependency on php :)

Thanks!
-agentzh

[agentzh]

On Thu, Jun 16, 2011 at 1:08 PM, agentzh [email protected] wrote:

And i think the problem with the logins that are not working (on wordpress, phpmyadmin, etc.) the issue is in ngx.location.capture not sending the body-data at the moment.

Some things that could confirm my assumption:

using as rewrite_by_lua_file:

I'll look into this. But it'll also be great if you can code up a
failing test case for it and removing the dependency on php :)

I cannot reproduce it using nginx 1.0.4 + latest ngx_lua master +
php-fpm 5.2.8 on Slackware Linux x86_64. Here's my setup:

# nginx.conf
location /info.php {
    fastcgi_param SCRIPT_FILENAME /tmp/test.php;
    fastcgi_param  REQUEST_METHOD     $request_method;
    fastcgi_param  CONTENT_LENGTH     $content_length;
    fastcgi_param  CONTENT_TYPE       $content_type;

    fastcgi_param REMOTE_ADDR $remote_addr;
    fastcgi_pass unix:/path/to/php-fpm/fastcgi.sock;
}
location /foo {
    rewrite_by_lua '
        res = ngx.location.capture("/info.php", {method =

ngx.HTTP_POST, body = "foo"})
ngx.print(res.body)
ngx.exit(200);
';
echo hello;
}

and here's the content of my /tmp/test.php:

<?php
    $body = file_get_contents('php://input');
    echo "request body: [$body]"
?>

Then GET /foo gives

 request body: [foo]

which is what we expected.

Regards,
-agentzh

Hi, i'm sorry - but i just found out, that the error with the lost body only occurs on my virtual machine where i was developing the last few days (Ubuntu 10.04 with php-fpm running from ppa)

I just did a clean install of nginx 1.0.4 with the latest ngx_dev_kit and lua-module on my own ArchLinux system (using latests php, too) and everything worked fine. So, the issue is on my side (some misconfiguration or so ... sorry again :( )

The other thing with locations not ending with a / is existing on this system, too.
I don't think that a case for the testsuite can reproduce this behaviour, because you have to create the specific locations there manually.

The error occurs, when there is a subfolder in the main html-directory of the location.
E.g. the main location "/" points to the "html"-folder and in the filesystem exists "html/foo" (in which is a index.php with a simple echo - like this: ~/nginx/html/foo/index.php)

When i point to http://domain.tld/foo/index.php or http://domain.tld/foo/ everything works correct. Only when using http://domain.tld/foo nginx returns a 301-error.
This is the reason, why i don't know, if a testcase can be written for that, because "foo" only exists in the filesystem and not as a location-entry.

It will fail with this code on my machines:

if ngx.is_subrequest == false then

        res = ngx.location.capture(ngx.var.request_uri)

        ngx.log(ngx.ERR, "SUBR. URI: " .. ngx.var.request_uri .. " | RES.STATUS: " .. res.status .. " | RES.BODY: " .. res.body)

        for i,j in pairs(res.header) do ngx.header[i] = j end

        ngx.print(res.body)
        ngx.exit(res.status)

end

The log-output here is this after 2 requests on foo/ and only foo

2011/06/16 09:42:34 [error] 27169#0: *14 SUBR. URI: /foo | RES.STATUS: 301 | RES.BODY: , client: 127.0.0.1, server: localhost, request: "GET /foo HTTP/1.1", host: "localhost:31337"
2011/06/16 09:42:43 [error] 27169#0: *14 SUBR. URI: /foo/ | RES.STATUS: 200 | RES.BODY: foo while sending to client, client: 127.0.0.1, server: localhost, request: "GET /foo/ HTTP/1.1", host: "localhost:31337"

Thanks, moody

[agentzh]

On Thu, Jun 16, 2011 at 3:44 PM, moodydeath
[email protected]
wrote:

Hi, i'm sorry - but i just found out, that the error with the lost body only occurs on my virtual machine where i was developing the last few days (Ubuntu 10.04 with php-fpm running from ppa)

I just did a clean install of nginx 1.0.4 with the latest ngx_dev_kit and lua-module on my own ArchLinux system (using latests php, too) and everything worked fine. So, the issue is on my side (some misconfiguration or so ... sorry again :( )

Nice to hear that it does not exist :D

The other thing with locations not ending with a / is existing on this system, too.
I don't think that a case for the testsuite can reproduce this behaviour, because you have to create the specific locations there manually.

I'll look into this one soon :)

Thanks!
-agentzh

[agentzh]

On Thu, Jun 16, 2011 at 3:44 PM, moodydeath
[email protected]
wrote:

The error occurs, when there is a subfolder in the main html-directory of the location.
E.g. the main location "/" poins to the "html"-folder and in the filesystem exists "html/foo" (in which is a index.php with a simple echo - like this: ~/nginx/html/foo/index.php)

When i point to http://domain.tld/foo/index.php or http://domain.tld/foo/ everything works correct. Only when http://domain.tld/foo nginx returns a 301-error.

I think this behavior is expected. A 301 redirect is sent to rewrite
/foo to /foo/ so as to resolve the famous "trailing slash problem". I
don't think this is a true "error". You can check out if the Location
response header of the 301 error page is something like "/foo/".

Cheers,
-agentzh

You're right, the original request without any lua-code interfering returns a 301 with a Location-header to the one with the / in the ending...

But when it's done through the lua-code, there is the 301 - but no Location-header to be able to redirect the client.
Normally all headers are sent from the subrequest to the response by this line:

for i,j in pairs(res.header) do ngx.header[i] = j end

This works e.g. for the login in phpmyadmin pretty well. it returns a 302 with a location-header to the new one (includeing the sessionid, etc.). So the lua-code should be able to handle this with a 301 without problems, i think.

With lua active the Response headers include: status, server, date, content-type, content-length, connection
Without lua, there's location, too...

the location-header for the 301 is not in the header-table generated by the subrequest. res.header["Location"] is empty.

Thanks, moody

[agentzh]

On Thu, Jun 16, 2011 at 4:15 PM, moodydeath
[email protected]
wrote:

You're right, the original request without any lua-code interfering returns a 301 with a Location-header to the one with the / in the ending...

But when it's done through the lua-code, there is the 301 - but no Location-header to be able to redirect the client.

Okay, I think I've found the reason :) It's indeed a bug in ngx_lua.
For this 301 error page, it's generated by nginx's rewrite rule, hence
only r->headers_out.location is set but no such entry in the
r->headers_out.headers list yet. The post subrequest callback planted
by ngx_lua should take into account the r->headers_out.location entry
while generating the response header (Lua) table for the subrequest.

I'll fix this shortly.

Normally all headers are sent from the subrequest to the response by this line:

for i,j in pairs(res.header) do ngx.header[i] = j end

BTW, please add the following line here (before the first ngx.print call):

ngx.status = res.status

This works e.g. for the login in phpmyadmin pretty well. it returns a 302 with a location-header to the new one (includeing the sessionid, etc.). So the lua-code should be able to handle this with a 301 without problems, i think.

For your those 302 error pages, ngx_lua works because it is the php
backend that generates the Location header, and the header is already
in r->headers_out.headers.

With lua active the Response headers include: status, server, date, content-type, content-length, connection
Without lua, there's location, too...

When your Lua hook is disabled, nginx replies on the standard
ngx_http_header_filter_module to interpret r->headers_out.location. We
should do the same in our post_subrequest callback in ngx_lua too :)

the location-header for the 301 is not in the header-table generated by the subrequest. res.header["Location"] is empty.

That's the cause of the problem. I'll fix it.

Thanks for your current project! It helps spotting lots of interesting
bugs in ngx_lua :D

Thanks again!
-agentzh

[agentzh]

On Thu, Jun 16, 2011 at 4:32 PM, agentzh [email protected] wrote:

Okay, I think I've found the reason :) It's indeed a bug in ngx_lua.
For this 301 error page, it's generated by nginx's rewrite rule, hence
only r->headers_out.location is set but no such entry in the
r->headers_out.headers list yet. The post subrequest callback planted
by ngx_lua should take into account the r->headers_out.location entry
while generating the response header (Lua) table for the subrequest.

I'll fix this shortly.

I've just fixed this issue in my local working copy. I'll commit it
shortly after my test suite completes running.

BTW, I suggest you should use access_by_lua instead of rewrite_by_lua
in your config because the former won't run in subrequests such that
you'll get better performance and no longer need the ngx.is_subrequest
test.

Thanks!
-agentzh

[agentzh]

On Thu, Jun 16, 2011 at 5:56 PM, agentzh [email protected] wrote:

I've just fixed this issue in my local working copy. I'll commit it
shortly after my test suite completes running.

Already committed to both master and devel :) Give it shot! :D

Thanks!
-agentzh

Yay, working perfect! :-)

Thanks for the tip with access_by...

Now the issue is really "closed" ;-)

moody

Gree