On Wed, Aug 03, 2022 at 08:39:32PM -0400, Jay Haines wrote:
Hi there,
> I am trying to weed out requests for any uri that contains the string,
> "announce" (no quotes). That would include
>
> * /announce
> * /announce/
> * /announce.php
Normal config there would be of the form
locat
I am trying to weed out requests for any uri that contains the string,
"announce" (no quotes). That would include
* /announce
* /announce/
* /announce.php
each with or without query strings. I have the following location blocks
in my server context:
location ~* announce {
On Tue, Nov 01, 2016 at 06:49:04PM -0400, olat wrote:
Hi there,
> I am asking about regex in the context of caching some
> of the requests on front-end proxy to speed up django app loading dynamic
> content where session is involved. Does it mean each of the filtered out
> requests we would like
On 02 Nov 2016, at 01:49, olat wrote:
> Looks like there is a bug in the forum. 2 the same topics and the response
> ended up in the wrong thread, mixed up ;-)
Yes, the forum has some issues when answer come from the mailing list.
> Anyway, Thanks Igor for a quick response. Could you explain mo
Looks like there is a bug in the forum. 2 the same topics and the response
ended up in the wrong thread, mixed up ;-)
Anyway, Thanks Igor for a quick response. Could you explain more why regex
is not a good idea? I am asking about regex in the context of caching some
of the requests on front-end p
On 01 Nov 2016, at 16:44, olat wrote:
> Hello,
>
> I would like to ask about regex. Why these 2 doesn't behave the same?
>
> location ~ /(apple/|pear/(small|big)/|test(ing|er)/(fruit|vegis)_)*
>
> location ~ /apple/*|/pear/(small|big)/*|/test(ing|er)/(fruit|vegis)_*
>
>
> could you point me
Hello,
I would like to ask about regex. Why these 2 doesn't behave the same?
location ~ /(apple/|pear/(small|big)/|test(ing|er)/(fruit|vegis)_)*
location ~ /apple/*|/pear/(small|big)/*|/test(ing|er)/(fruit|vegis)_*
could you point me to good practice?
Ola
Posted at Nginx Forum:
https://for
On 03/09/2016 01:24 PM, Francis Daly wrote:
> On Wed, Mar 09, 2016 at 11:31:08AM +, Peter Molnar wrote:
>
> Hi there,
>
>> I'm facing some strange, unexpected regex behaviour in my setup.
>
> I think the answer is at http://nginx.org/r/rewrite and the "last" flag.
You were right about this
On Wed, Mar 09, 2016 at 11:31:08AM +, Peter Molnar wrote:
Hi there,
> I'm facing some strange, unexpected regex behaviour in my setup.
I think the answer is at http://nginx.org/r/rewrite and the "last" flag.
What do you want to happen if the incoming request is for
/wp-content/cache/file-18
Dear nginx.org,
I'm facing some strange, unexpected regex behaviour in my setup.
Nginx is 1.9.12, self compiled, with openssl-1.0.2g and with the
following modules:
- echo-nginx-module (https://github.com/agentzh/echo-nginx-module.git)
- headers-more-nginx-module
(https://github.com/agentzh/header
I would use:
- rewrite directives only at server level, no need for location here
- a single regex with OR logic to match both the advancedsearch and the
profile URI since the rewriting grammar is the same
- a single regex for both 'index.php' rewritings, since the grammar of
category+page is the s
Hi.
I try to transform the pligg htaccess rules to nginx.
https://github.com/Pligg/pligg-cms/blob/master/htaccess.default
There is one from 2010
http://www.edwardawebb.com/web-development/running-pligg-nginx-rewrite-rules
this transformation have some optimization potential, imho ;-).
I woul
Hello,
Thanks for that... I thought the ^~ was meaning 'starting with regex'...
My bad!
I changed the symbol for some of the ones relly meaning 'regex' (~*)
and it works! :o)
If there is no better way than sticking with
'if', then it's all good.
Thanks again, problem solved,
---
*B. R.*
On S
On Sun, Mar 10, 2013 at 05:29:18AM -0400, B.R. wrote:
Hi there,
> The *correct* way:
> location ^~ /documents/(\w+) {
> set $user $1;
> if ($user != $remote_user) {
> return 503;
> }
> }
>
> Although the syntax is now OK and the configuration is able to be reloaded,
> it doe
6252/nginx-given-custom-subdomain-location-regex-matching-with-http-user-agent-con>
.
The *incorrect* way:
location ^~ /documents/(\w+) {
if ($1 != $remote_user) {
return 503;
}
}
*--> $1 variable is unknown*
The *correct* way:
location ^~ /documents/(\w+) {
set
Hello,
I am using basic auth + $remote_user variable send to the back-end
application to change context depending on the logged-in user.
The thing is, even if the page rendered by the back-end uses nginx user
authentication, resources from a directory are still allowed for everyone.
My 'document
16 matches
Mail list logo
