Nginx – Passthrough captured request in nginx with lua

luanginx

I'm doing something like this:

location /foo {
        content_by_lua_block {
            local reqType = ngx.var.request_method
            if reqType == "POST"
                res = ngx.location.capture("/bar")
            else
                res = ngx.location.capture("/baz")
            end
            ngx.say(res.body)
        }
    }

    location /bar {
        internal;
        #fastcgi, omitted
    }

    location /baz{
        internal;
        #fastcgi, omitted
    }
}

But the headers sent by PHP are lost and status code is always 200. Is there anyway to just send the original response? ngx.say() just output the response body, and I need to capture the entire request and send it to browser.

I'm using openresty/1.9.15.1

Edit: I found a way to do this, but if there exists any different way to do this, would be very appreciated.

Best Answer

This is possible using response properties:

response = ngx.location.capture("/bar")
for headerName, header in pairs(response.header) do
    ngx.header[headerName] = header
end
ngx.status = response.status
ngx.say(response.body)
ngx.exit(response.status)

Related Solutions

nginx – Removing Small Document Body in NGINX 301 and 302 Redirects

Think very carefully about what you're asking for, and strongly consider not doing it.

RFC 2616 specifies that the entity bodies you want to remove should be present.

10.3.2 301 Moved Permanently

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

and...

10.3.3 302 Found

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

SHOULD, in this context, is defined in RFC 2119:

This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Now you can do this without violating the RFC, but you should be aware of the full implications:

You are doing a lot of work for virtually no benefit. The only logical reason I can think of to disable the entity body is to save on bandwidth costs, and indeed this is the reason you mentioned, but the difference is so minimal that it's unlikely you'll even see a difference on your bandwidth graphs.
A very tiny fraction of web clients don't automatically follow 3xx redirects. This fraction was much larger when the RFC was written, which is why this is there in the first place, but there are still ancient monstrosities lurking in the shadows of dark bedrooms and data center closets, and sometimes they come out to play. The one you are most likely to see is curl, which is still in common use.

This recommendation has been relaxed somewhat with RFC 7231, which merely says (for both 301 and 302):

The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).

The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).

Nginx – php-fpm returning empty response to nginx

The standard factcgi_params file doesn't contain the key line for SCRIPT_FILENAME.

location ~ \.php$ {
                include fastcgi_params;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
}

Add it and restart nginx.

Best Answer

Related Solutions

nginx – Removing Small Document Body in NGINX 301 and 302 Redirects

Nginx – php-fpm returning empty response to nginx

Related Topic