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

[Maxim Dounin]

Hello!

On Mon, May 04, 2015 at 10:02:33AM +0200, Sergey Brester wrote:

> Am 30.04.2015 20:56, schrieb Maxim Dounin:
> 
> >> Hello!
> >>
> >> On Thu, Apr 30, 2015 at 07:13:01PM +0200, Sergey Brester wrote:
> >>
> >> 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.

As already explained, this is a wrong assumption.

> >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.
> >
> 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.

> >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.

-- 
Maxim Dounin
http://nginx.org/