I need to use php’s fastcgi for dir1 and dir2 but only to redirect
dir1 in https. To be honest I try many settings but without any
results.
It seems that fastcgi (or upstream) have always the priority on
location.
A solution could be to add a rewrite in the php’s location too to have
something like this (but that seems rally ugly to me):
root /www/;
(Possibly what you want is some other configuration: the important thing
to keep in mind is: for this request, which one location do you wish to
handle it? Then configure the locations accordingly.)
FYI I read the documentation before to send my first email but I
misunderstood the part about “^~” and also I didnt clearly realized
that “One request is handled in one location”.
So with your clarification I was able to make something working:
It seems to work as expected; I guess I could use “^~” too but I
didn’t tried yet.
At first I wanted to avoid repetition of the php-fpm’s part but I
didn’t realized that it wasn’t doable.
Thanks for your help and again this is really appreciated!
I’ve tried various combinations of burst=2, nodelay, 1r/s or 1r/m, with
and
without limit_conn, with and without keepalive, with and without
“location
/”, etc… and requests are never being limited, as shown by the
access.log
entries below:
English is not my native language and I’m really bad at it so this can
be the explanation of my misunderstanding.
Anyway maybe the section about location could be reorganized a bit to
explain possibilities ([ = | ~ | ~* | ^~ ]) in a dedicated part.
That looks reasonable. “^~” only matters if you have (top level) regex
matches – which here, you don’t.
(Avoiding top level regex matches makes it very easy to know which
location{} will match any particular request. That’s usually considered
a Good Thing.)
Ok, good to know.
In this case, you want different fastcgi_param lines for different php
scripts – so repeating the common config (by using “include”) and adding
the specific parts, like you have done, is probably the best way.
Thanks for this confirmation.
English is not my native language and I’m really bad at it so this can
be the explanation of my misunderstanding.
Anyway maybe the section about location could be reorganized a bit to
explain possibilities ([ = | ~ | ~* | ^~ ]) in a dedicated part.
English isn’t my native language, too, but regular expressions
(“regex” resp. “RegExp”) is such a wide-spreaded topic, that you could
read about the basics at wikipedia, too →
Choose the translation in your mother tongue at the left hand sidebar
(“regex” resp. “RegExp”) is such a wide-spreaded topic, that you could
read about the basics at wikipedia, too → Regular expression - Wikipedia
Choose the translation in your mother tongue at the left hand sidebar
On Tue, Oct 09, 2012 at 04:50:32PM +0200, Thomas M. wrote:
Hi there,
great that you found a configuration that works.
FYI I read the documentation before to send my first email but I
misunderstood the part about “^~” and also I didn’t clearly realized
that “One request is handled in one location”.
Having re-read the docs, I can see that the interpretation could be
made clearer. Can you suggest any wording that might have helped you
understand then, what you do now? Maybe it can become easier for the
next person
It seems to work as expected; I guess I could use “^~” too but I
didn’t tried yet.
That looks reasonable. “^~” only matters if you have (top level) regex
matches – which here, you don’t.
(Avoiding top level regex matches makes it very easy to know which
location{} will match any particular request. That’s usually considered
a Good Thing.)
At first I wanted to avoid repetition of the php-fpm’s part but I
didn’t realized that it wasn’t doable.
In this case, you want different fastcgi_param lines for different php
scripts – so repeating the common config (by using “include”) and
adding
the specific parts, like you have done, is probably the best way.
Thanks for your help and again this is really appreciated!