headers
Wayne E. Seguin | 1 Apr 2007 04:43
Picon

Re: Proxying header question


On Mar 31, 2007, at 16:26 , Igor Sysoev wrote:

> On Fri, Mar 23, 2007 at 07:40:03PM -0400, Wayne E. Seguin wrote:
>
>> I'm trying to setup dynamic handling based on the subdomain asked for
>> in an application that is proxied to.
>>
>> Basically I'm using:
>>
>> upstream http://domain.tld {
>
> -upstream http://domain.tld {
> +upstream domain.tld {
>
>> ...
>> }
>>
>> server {
>>   location / {
>>     proxy_set_header  X-Real-IP  $remote_addr;
>>     proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
>>     proxy_set_header Host $http_host;
>
> -     proxy_set_header Host $http_host;
> +     proxy_set_header Host $host;
>
>>     proxy_redirect false;
>
> -     proxy_redirect false;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Igor Sysoev | 1 Apr 2007 09:19
Picon

Re: Proxying header question

On Sat, Mar 31, 2007 at 10:43:51PM -0400, Wayne E. Seguin wrote:

> On Mar 31, 2007, at 16:26 , Igor Sysoev wrote:
> 
> >On Fri, Mar 23, 2007 at 07:40:03PM -0400, Wayne E. Seguin wrote:
> >
> >>I'm trying to setup dynamic handling based on the subdomain asked for
> >>in an application that is proxied to.
> >>
> >>Basically I'm using:
> >>
> >>upstream http://domain.tld {
> >
> >-upstream http://domain.tld {
> >+upstream domain.tld {
> >
> >>...
> >>}
> >>
> >>server {
> >>  location / {
> >>    proxy_set_header  X-Real-IP  $remote_addr;
> >>    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
> >>    proxy_set_header Host $http_host;
> >
> >-     proxy_set_header Host $http_host;
> >+     proxy_set_header Host $host;
> >
> >>    proxy_redirect false;
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicholas Riley | 2 Apr 2007 07:49
Picon

Re: SSL proxy corruption

On Sat, Mar 31, 2007 at 11:50:01PM +0400, Igor Sysoev wrote:
> The attached patch should fix the bug.

Looks to do it for us.  Thanks!

--

-- 
Nicholas Riley <njriley@...> | <http://www.uiuc.edu/ph/www/njriley>
Permalink | Reply | 0 comments |
headers
Igor Sysoev | 2 Apr 2007 12:47
Picon

nginx-0.5.17

Changes with nginx 0.5.17                                        02 Apr 2007

    *) Change: now nginx always returns the 405 status for the TRACE method.

    *) Feature: now nginx supports the "include" directive inside the 
       "types" block.

    *) Bugfix: the $document_root variable usage in the "root" and "alias" 
       directives is disabled: this caused recursive stack overflow.

    *) Bugfix: in the HTTPS protocol in the "proxy_pass" directive.

    *) Bugfix: in some cases non-cachable variables (such as $uri variable) 
       returned old cached value.

--

-- 
Igor Sysoev
http://sysoev.ru/en/
Permalink | Reply | 0 comments |
headers
Wilson Bilkovich | 2 Apr 2007 13:41
Picon
Gravatar

Trouble with a complex rewrite

I am migrating an existing Apache 2.2.4 -> Mongrel configuration to Nginx.
Everything is working fine save for one final piece.

We have a complicated rule that redirects some traffic to a partner
site based on the contents of the query string. At the moment, this is
still a requirement, and I can't do away with it.

The existing Apache rule is:

RewriteCond %{QUERY_STRING} message=.*(%\d+|\b)(foo|bar|baz|qux)(%\d+|\b) [NC]
RewriteRule ^/api/receive
http://target.example.com/horrible/url/?%{QUERY_STRING} [P,L,NC]

The nasty piece here is that "%\d+" in the regexp pattern is
necessary. 'foo' should only match if it is a whole word in the query
string.
(%\d+|\b) allows the pattern to handle either normal word boundaries,
or HTML-encoded entities like %20.
For example:
api/receive?message=foo%20hello should match this rule, but:
api/receive?message=hellofoo should not

Is it possible to duplicate this in nginx?
Thus far I have tried:
1. Making a location {} entry for api/receive, and using if
($query_string ~ pattern)
2. Using if($query_string) inside the / location block
3. Making a location entry for the regexp on its own
4. Testing with simply message=.*foo as the pattern, which makes me
think the problem is more basic than the regexp pattern
(Continue reading)

Permalink | Reply | 12 comments |
headers
Igor Sysoev | 2 Apr 2007 14:25
Picon

Re: Trouble with a complex rewrite

On Mon, Apr 02, 2007 at 07:41:09AM -0400, Wilson Bilkovich wrote:

> I am migrating an existing Apache 2.2.4 -> Mongrel configuration to Nginx.
> Everything is working fine save for one final piece.
> 
> We have a complicated rule that redirects some traffic to a partner
> site based on the contents of the query string. At the moment, this is
> still a requirement, and I can't do away with it.
> 
> The existing Apache rule is:
> 
> RewriteCond %{QUERY_STRING} message=.*(%\d+|\b)(foo|bar|baz|qux)(%\d+|\b) 
> [NC]
> RewriteRule ^/api/receive
> http://target.example.com/horrible/url/?%{QUERY_STRING} [P,L,NC]
> 
> The nasty piece here is that "%\d+" in the regexp pattern is
> necessary. 'foo' should only match if it is a whole word in the query
> string.
> (%\d+|\b) allows the pattern to handle either normal word boundaries,
> or HTML-encoded entities like %20.
> For example:
> api/receive?message=foo%20hello should match this rule, but:
> api/receive?message=hellofoo should not
> 
> Is it possible to duplicate this in nginx?
> Thus far I have tried:
> 1. Making a location {} entry for api/receive, and using if
> ($query_string ~ pattern)
> 2. Using if($query_string) inside the / location block
(Continue reading)

Permalink | Reply | 11 comments |
headers
Wilson Bilkovich | 2 Apr 2007 21:15
Picon
Gravatar

Re: Trouble with a complex rewrite

On 4/2/07, Igor Sysoev <is@...> wrote:
> On Mon, Apr 02, 2007 at 07:41:09AM -0400, Wilson Bilkovich wrote:
>
> > I am migrating an existing Apache 2.2.4 -> Mongrel configuration to Nginx.
> > Everything is working fine save for one final piece.
> >
> > We have a complicated rule that redirects some traffic to a partner
> > site based on the contents of the query string. At the moment, this is
> > still a requirement, and I can't do away with it.
> >
> > The existing Apache rule is:
> >
> > RewriteCond %{QUERY_STRING} message=.*(%\d+|\b)(foo|bar|baz|qux)(%\d+|\b)
> > [NC]
> > RewriteRule ^/api/receive
> > http://target.example.com/horrible/url/?%{QUERY_STRING} [P,L,NC]
> >
> > The nasty piece here is that "%\d+" in the regexp pattern is
> > necessary. 'foo' should only match if it is a whole word in the query
> > string.
> > (%\d+|\b) allows the pattern to handle either normal word boundaries,
> > or HTML-encoded entities like %20.
> > For example:
> > api/receive?message=foo%20hello should match this rule, but:
> > api/receive?message=hellofoo should not
> >
> > Is it possible to duplicate this in nginx?
> > Thus far I have tried:
> > 1. Making a location {} entry for api/receive, and using if
> > ($query_string ~ pattern)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Igor Sysoev | 2 Apr 2007 21:47
Picon

Re: Trouble with a complex rewrite

On Mon, Apr 02, 2007 at 03:15:12PM -0400, Wilson Bilkovich wrote:

> On 4/2/07, Igor Sysoev <is@...> wrote:
> >On Mon, Apr 02, 2007 at 07:41:09AM -0400, Wilson Bilkovich wrote:
> >
> >> I am migrating an existing Apache 2.2.4 -> Mongrel configuration to 
> >Nginx.
> >> Everything is working fine save for one final piece.
> >>
> >> We have a complicated rule that redirects some traffic to a partner
> >> site based on the contents of the query string. At the moment, this is
> >> still a requirement, and I can't do away with it.
> >>
> >> The existing Apache rule is:
> >>
> >> RewriteCond %{QUERY_STRING} message=.*(%\d+|\b)(foo|bar|baz|qux)(%\d+|\b)
> >> [NC]
> >> RewriteRule ^/api/receive
> >> http://target.example.com/horrible/url/?%{QUERY_STRING} [P,L,NC]
> >>
> >> The nasty piece here is that "%\d+" in the regexp pattern is
> >> necessary. 'foo' should only match if it is a whole word in the query
> >> string.
> >> (%\d+|\b) allows the pattern to handle either normal word boundaries,
> >> or HTML-encoded entities like %20.
> >> For example:
> >> api/receive?message=foo%20hello should match this rule, but:
> >> api/receive?message=hellofoo should not
> >>
> >> Is it possible to duplicate this in nginx?
(Continue reading)

Permalink | Reply | 9 comments |
headers
Wilson Bilkovich | 2 Apr 2007 21:55
Picon
Gravatar

Re: Trouble with a complex rewrite

On 4/2/07, Igor Sysoev <is@...> wrote:
> On Mon, Apr 02, 2007 at 03:15:12PM -0400, Wilson Bilkovich wrote:
>
> > On 4/2/07, Igor Sysoev <is@...> wrote:
> > >On Mon, Apr 02, 2007 at 07:41:09AM -0400, Wilson Bilkovich wrote:
> > >
> > >> I am migrating an existing Apache 2.2.4 -> Mongrel configuration to
> > >Nginx.
> > >> Everything is working fine save for one final piece.
> > >>
> > >> We have a complicated rule that redirects some traffic to a partner
> > >> site based on the contents of the query string. At the moment, this is
> > >> still a requirement, and I can't do away with it.
> > >>
> > >> The existing Apache rule is:
> > >>
> > >> RewriteCond %{QUERY_STRING} message=.*(%\d+|\b)(foo|bar|baz|qux)(%\d+|\b)
> > >> [NC]
> > >> RewriteRule ^/api/receive
> > >> http://target.example.com/horrible/url/?%{QUERY_STRING} [P,L,NC]
> > >>
> > >> The nasty piece here is that "%\d+" in the regexp pattern is
> > >> necessary. 'foo' should only match if it is a whole word in the query
> > >> string.
> > >> (%\d+|\b) allows the pattern to handle either normal word boundaries,
> > >> or HTML-encoded entities like %20.
> > >> For example:
> > >> api/receive?message=foo%20hello should match this rule, but:
> > >> api/receive?message=hellofoo should not
> > >>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Igor Sysoev | 2 Apr 2007 22:19
Picon

Re: Trouble with a complex rewrite

On Mon, Apr 02, 2007 at 03:55:20PM -0400, Wilson Bilkovich wrote:

> I have two more questions about this:
> 1. I can use any regular expression supported by PCRE, anywhere in my
> nginx config, correct?

The regexp engine is PCRE.

The regexp are supported in some directives only:
"if", "rewrite", and "location".

> 2. When I have nested locations, such as:
> location / {
>  location /api/receive {
>    break;
>  }
>  some_config_option on;
> }
> 
> Configuration options in the outer scope (location /, in this case)
> are always evaluated, despite the break command?
> In other words, break only 'breaks' from the location / rewrite loop,
> not from the rest of the configuration?

If the "rewrite" directive has rewritten URI, then nginx search the new
location configuration. The "break" stops this rewrite cycle.

The nested locations are not fully supported, you should use

   location / {
(Continue reading)

Permalink | Reply | 7 comments |

Gmane