On Tue, Sep 18, 2018 at 08:12:20AM -0400, Thomas Ward wrote:
> Downstream in Ubuntu, it has been proposed to demote pcre3 and
> use pcre2 instead as it is newer.
> https://trac.nginx.org/nginx/ticket/720 shows it was marked 4
> years ago that NGINX does not support pcre2. Are there any
> plans to use pcre2 instead of pcre3?
There are no immediate plans.
When we last checked, there were no problems with PCRE, but PCRE2
wasn't available in most distributions we support, making the
switch mostly meaningless.
Also, it looks like PCRE2 is still not supported even by Exim,
which is the parent project of PCRE and PCRE2:
As such, adding PCRE2 support to nginx looks premature.
First of all, ignore patch in first mail, I don't use mercurial on
daily basis, and my neomutt screwed the patch. Second mail in thread
contains just patch and it seems to be correct.
I wanted to address few other things on the subject. I started my way
however decisions done there I found incorrect. Author tried to jump
right into XCLIENT from PROXY PROTOCOL. In proposed implementation proxy
protocol is handled in the begining of connections. Since XCLIENT gets
its address from ngx_connection_s, it will get automatically downstream
provided address of client.
In the same thread, there was questions on how to deal with
"real_ip_header" and "set_real_ip_from". As I mentioned in the original
description to the patch, one may need these in case of HTTP protocol,
which is very flexible, with tons of applications behind that may demand
presense of real ip address in different places/headers. For ancient mail
protocols, it is not the case. They are very strict, very few
applications that implement it, probably Postfix, Exim and Dovecot be
the only practical implementations. And they do support proxy protocol
out of the box. So I could not find real reason to apply "real_ip"
thing. With proposed implementation, it just worked out of the box, with
minimum configuration. The only thing which could be added if need is
the overriding of "destination address" of proxy protocol (i.e. address
which client reached). For now I didn't see where it could be useful in
mentioned above mail applications. Client address, yes, we do pass,
server address ¯\_(ツ)_/¯, who cares.
I can't seem to set a few of the quic parameters using their respective
Specifically, doing e.g. this in the conf:
* quic_max_udp_payload_size 1472;*
* quic_max_ack_delay 10;*
* quic_ack_delay_exponent 2;*
... results in the default values being sent (as seen in qvis):
* "max_packet_size": 65527 "max_ack_delay": 25
Other parameters (like quic_inital_*) are being set just fine. Any idea
what I might be doing wrong for these 3 above?
p.s. I think *quic_max_packet_size* needs to be updated to
*quic_max_udp_payload_size* in the README to match the latest drafts and