nginx http-core enhancement: named location in subrequests + directive use_location

[Sergey Brester]

Hi,

enclosed you will find an attached changeset, that:

- allows to fast use of named location in sub requests, such as
auth_request, etc. Currently no named location was possible in any sub
requests, real (or internal) locations only.

# now you can use named location in sub requests:
# auth_request /auth_loc/;
auth_request @auth_loc;

- in addition, a second mini-commit (37d7786e7015) with new directive
"use_location" as alias or replacement for "try_files" with no file
argument and without checking the existence of file(s):

# try_files "" @loc
use_location @loc

It was allready more times discussed (goto location, etc.).

PS. If someone needs a git version of it:
https://github.com/sebres/nginx/commits/hg-sb-mod [1]

Regards,

sebres.

Links:
------
[1] https://github.com/sebres/nginx/commits/hg-sb-mod

[Maxim Dounin]

Hello!

Post by Sergey Brester
Hi,
- allows to fast use of named location in sub requests, such as
auth_request, etc. Currently no named location was possible in any sub
requests, real (or internal) locations only.
# auth_request /auth_loc/;
- in addition, a second mini-commit (37d7786e7015) with new directive
"use_location" as alias or replacement for "try_files" with no file
It was allready more times discussed (goto location, etc.).
https://github.com/sebres/nginx/commits/hg-sb-mod [1]
Regards,
sebres.
------
[1] https://github.com/sebres/nginx/commits/hg-sb-mod
# HG changeset patch
# Date 1430227790 -7200
# Tue Apr 28 15:29:50 2015 +0200
# Node ID 37d7786e7015f8a784e6a4dc3f88f8a7573a4c08
# Parent 96e22e4f1b03ff15a774c6ed34d74b897af32c55
http-core: new directive "use_location" as replacement or alias for "try_files" with no file

Something like this was previously discussed more than once, and
the short answer is "no".

Post by Sergey Brester
# HG changeset patch
# Date 1430228073 -7200
# Tue Apr 28 15:34:33 2015 +0200
# Node ID 43135346275c76add5bf953024a3d244f04184ba
# Parent 37d7786e7015f8a784e6a4dc3f88f8a7573a4c08
http-core: allow to fast use of named location in (internal) sub requests, ex.: auth_request, etc.;
diff -r 37d7786e7015 -r 43135346275c src/http/ngx_http_core_module.c
--- a/src/http/ngx_http_core_module.c Tue Apr 28 15:29:50 2015 +0200
+++ b/src/http/ngx_http_core_module.c Tue Apr 28 15:34:33 2015 +0200
@@ -22,6 +22,7 @@ typedef struct {
static ngx_int_t ngx_http_core_find_location(ngx_http_request_t *r);
+static ngx_int_t ngx_http_core_find_named_location(ngx_http_request_t *r, ngx_str_t *name);
static ngx_int_t ngx_http_core_find_static_location(ngx_http_request_t *r,
ngx_http_location_tree_node_t *node);
@@ -1542,6 +1543,16 @@ ngx_http_core_find_location(ngx_http_req
noregex = 0;
#endif
+ /* already internal - check is resp. can be named location - search it */
+
+
+ if (ngx_http_core_find_named_location(r, &r->uri) == NGX_OK) {
+
+ return NGX_OK;
+ }
+ }
+

And how it's expected to be processed in a named location if
r->uri is "@..."?

Note that named locations are ones where requests are handled with
their original URIs unmodified. This, in particular, allows to
use the original URI to select a file, or in a request to the
upstream server, etc. With what you are trying to do it doesn't
look different from a static location.

[Sergey Brester]

Post by Maxim Dounin
Hello!
Something like this was previously discussed more than once, and
the short answer is "no".
And how it's expected to be processed in a named location if

Function "ngx_http_core_find_named_location" if location was found set
"r->loc_conf = (*clcfp)->loc_conf" and returns NGX_OK.

Post by Maxim Dounin
Note that named locations are ones where requests are handled with their original URIs unmodified. This, in particular, allows to use the original URI to select a file, or in a request to the upstream server, etc. With what you are trying to do it doesn't look different from a static location

As I wrote it already (of course it is not a static location):

Example, instead of :

# auth_request /auth_loc/;

You can use named location @auth_loc and write now:

auth_request @auth_loc;

Regards,
sebres.

Links:
------
[1] https://github.com/sebres/nginx/commits/hg-sb-mod

[Maxim Dounin]

Hello!

On Wed, Apr 29, 2015 at 07:22:51PM +0200, Sergey Brester wrote:

[...]

Post by Sergey Brester

Post by Maxim Dounin
And how it's expected to be processed in a named location if

Function "ngx_http_core_find_named_location" if location was found set
"r->loc_conf = (*clcfp)->loc_conf" and returns NGX_OK.

The problem is that the r->uri will be illegal.

Post by Sergey Brester

Post by Maxim Dounin
Note that named locations are ones where requests are handled
with their original URIs unmodified. This, in particular,
allows to use the original URI to select a file, or in a
request to the upstream server, etc. With what you are trying
to do it doesn't look different from a static location

# auth_request /auth_loc/;

So what will happen if the location is:

location @auth_loc {
proxy_pass http://auth.backend;
}

Which URI will be used in a HTTP request to auth.backend? As far
as I see, with your code it will result in a

GET @auth_loc HTTP/1.0

request to the upstream server, and immediate 400 response is what
will happen.

[Sergey Brester]

Post by Maxim Dounin
Hello!
[...]

The problem is that the r->uri will be illegal.

I think not for internal request?!

if (r->internal && r->uri...
So what will happen if the location is:

location @auth_loc {
proxy_pass http://auth.backend [1];
}

Which URI will be used in a HTTP request to auth.backend? As far
as I see, with your code it will result in a

GET @auth_loc HTTP/1.0

request to the upstream server, and immediate 400 response is what
will happen.

Yes, in this case the backend upstream should support such uri's or more
likely in named location it should be overwritten...

But for subrequests (example for auth_request) is anyway original
"document_uri" resp. "script_name" more interesting...
Anyway if proxy_pass should use real uri with "/" you can still use
"normal" named convention for nonnamed internal location.

Here is my config for example:

location @cgisvc_auth1 {
fastcgi_keep_conn on;
include fastcgi_params;
fastcgi_pass_request_body off;
fastcgi_pass http_cgi_backend;
}

location @cgisvc_auth2 {
proxy_pass http://localhost:8088/ [1];
}

location /test1 {
auth_request @cgisvc_auth1;
}

location /test2 {
auth_request @cgisvc_auth2;
}

Links:
------
[1] http://auth.backend

[Maxim Dounin]

Hello!

Post by Sergey Brester

Post by Maxim Dounin
On Wed, Apr 29, 2015 at 07:22:51PM +0200, Sergey Brester

Post by Maxim Dounin
And how it's expected to be processed in a named location if
"ngx_http_core_find_named_location" if location was found
set "r->loc_conf = (*clcfp)->loc_conf" and returns NGX_OK.

The problem is that the r->uri will be illegal.

I think not for internal request?!
if (r->internal && r->uri...

You think it's not a problem, or you think it won't be illegal?

While it's not generally a problem for nginx if an URI in an
internal request becomes illegal, it's certainly not a case we are
going to promote by applying patches. If illegal URIs are ok for
you, you may just use something like

auth_request @foo;

location = @foo {
...
}

And it will work right now out of the box.

What you are trying to do is to misuse named locations as static
locations with some invalid URIs. This is wrong, named locations
are different. They preserve URI of a request untouched. That's
their main property and main advantage.

(BTW, please use plain text for further messages, I'm a bit bored
to fix quoting in what your mail client produces as a plain text
version. Thank you.)

[Sergey Brester]

Post by Maxim Dounin

Post by Maxim Dounin
Hello!
I think not for internal request?! if (r->internal && r->uri...

You think it's not a problem, or you think it won't be illegal?

What I meant was, it is for internal request only - so If I itself want
use named location (with @), I must take care about uri, will be passed
to the backend.

Post by Maxim Dounin
While it's not generally a problem for nginx if an URI in an
internal request becomes illegal, it's certainly not a case we are
going to promote by applying patches. If illegal URIs are ok for
you, you may just use something like
...
}
And it will work right now out of the box.

Yes, but not as NAMED location! With everything what belongs to
(slowly).

Post by Maxim Dounin
What you are trying to do is to misuse named locations as static
locations with some invalid URIs. This is wrong, named locations
are different. They preserve URI of a request untouched. That's
their main property and main advantage.

Now little bit understandable, what you mean. What can I do, to prevent
changing uri in this case?
I've taken simply existing code and packaged as
ngx_http_core_find_named_location

Post by Maxim Dounin
(BTW, please use plain text for further messages, I'm a bit bored
to fix quoting in what your mail client produces as a plain text
version. Thank you.)

Sorry now as plain (but it is more likely your client:)

[Maxim Dounin]

Hello!

Post by Maxim Dounin

Post by Maxim Dounin
Hello!
I think not for internal request?! if (r->internal && r->uri...

You think it's not a problem, or you think it won't be illegal?

What I meant was, it is for internal request only - so If I itself want use
backend.

As already explained, this is a wrong assumption.

Post by Maxim Dounin
While it's not generally a problem for nginx if an URI in an
internal request becomes illegal, it's certainly not a case we are
going to promote by applying patches. If illegal URIs are ok for
you, you may just use something like
...
}
And it will work right now out of the box.

Yes, but not as NAMED location! With everything what belongs to (slowly).

As long as you don't use the only property of named locations, you
don't need them and can use static locations instead.

Post by Maxim Dounin
What you are trying to do is to misuse named locations as static
locations with some invalid URIs. This is wrong, named locations
are different. They preserve URI of a request untouched. That's
their main property and main advantage.

Now little bit understandable, what you mean. What can I do, to prevent
changing uri in this case?
I've taken simply existing code and packaged as
ngx_http_core_find_named_location

I've reviewed the patch you've proposed and explained why it's
obviously wrong. Proper implementation should be very different.
I haven't looked into details, but may be just a
ngx_http_named_location() call after a subrequest was created will
do the trick.