On Tue, Apr 12, 2022 at 10:30:29PM +0300, Sergey A. Osokin wrote:
On Tue, Apr 12, 2022 at 05:04:19PM +, Scott Snow wrote:
Sergey -
Thanks for the quick reply.
Note I am not asking after format of message content akin to what's
available for access_log, just the interpretation of the numer
On Tue, Apr 12, 2022 at 05:04:19PM +, Scott Snow wrote:
> Sergey -
> Thanks for the quick reply.
>
> Note I am not asking after format of message content akin to what's
> available for access_log, just the interpretation of the numerical parts
> of the apparent pattern in the error_log message
Hello,
I'm glad to announce a new release of NGINX JavaScript module (njs).
This release focuses on stabilization of recently released features
including async/await and fixing bugs found by various fuzzers.
Learn more about njs:
- Overview and introduction:https://nginx.org/en/docs/njs/
- NGI
Sergey -
Thanks for the quick reply.
Note I am not asking after format of message content akin to what's available
for access_log,
just the interpretation of the numerical parts of the apparent pattern in the
error_log messages posted:
"[] # : "
Perhaps you mean even the "[] #" isn't fixed or
Hi Scott,
hope you're doing well.
The error_log directive is documented well [1].
There's no format of error messages.
While I'm here I'd recommend to keep 72 characters per line, that helps
a lot to read emails, thank you.
References:
[1] https://nginx.org/en/docs/ngx_core_module.html#error_lo
Is there documentation for the format of error messages nginx posted to
error_log?
Specifically, following the level in square brackets are two numbers separated
by '#'; what do these represent?
For instance, the message on the page Advanced Configuration with Snippets |
NGINX Ingress
Controlle
Thank you very much, Francis!
Indeed, it was a permission issue on the filesystem.
Again, my bad! Sorry to bother this mailing list with this basic issue.
On Tue, Apr 12, 2022 at 8:22 AM Francis Daly wrote:
>
> On Mon, Apr 11, 2022 at 10:02:40AM -0300, Fabiano Furtado Pessoa Coelho wrote:
>
> H
Hello Gilles,
A browser won't send URL postion after the '#' mark to a web server.
So your maps won't work as expected and there is nothing to do in Nginx
about it.
Regards,
Igor.
On 12.04.2022 10:16, gperrot wrote:
Hello,
I am using nginx/1.16.1 on CentOS Linux 7. I am using map directive
Hi,
hope you're doing well these days.
The best way to debug such situations is to enable a debugging log [1].
Hope that helps.
While I'm here I'd recommend to upgrade nginx instance to the
more recent stable version, i.e. 1.20.2.
References:
[1] https://nginx.org/en/docs/debugging_log.html
--
Hi Dimitre,
On 11.04.2022 19:52, dimitre wrote:
First of all thanks for all the hard work on the best server out there.
I'm now using the experimental QUIC branch. I've noticed developent stalled
about two months ago, both QUIC and mainline.
As I knew about Igor departure this year I'm kind of c
On Mon, Apr 11, 2022 at 10:02:40AM -0300, Fabiano Furtado Pessoa Coelho wrote:
Hi there,
> I've one more question about an access_log weird behavior, when it's
> configured with a $1 regex return variable.
http://nginx.org/r/access_log -- The file path can contain variables
> For instance:
>
>
Hello,
I am using nginx/1.16.1 on CentOS Linux 7. I am using map directive for
managing a large number of redirects from one server to another server :
map $request_uri $new_uri {
include /etc/nginx/conf/redirect.map;
include /etc/nginx/conf/documentation.map;
}
In /etc/nginx/conf/docum
12 matches
Mail list logo
