PCRE2 support?

[Mark Mielke]

On Tue, Sep 18, 2018 at 11:55 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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.
>

I think there have been changes since then. PCRE2 was new in 2015, but
isn't new in 2018.

RHEL 7 (and clones) include libpcre2. I think this is a pretty wide set of
machines right here. I believe Ubuntu 16.04 LTS has libpcre2 which is
another wide set. Fedora has had it for a while now. I think that unless
you go to older releases, all major distributions should have PCRE2 by now.

I build haproxy with PCRE2 support.

One that was interesting to me, is that Git recently (April, 2018?)
switched to building with PCRE2 by default when "USE_LIBPCRE=Yes" was
specified:

https://github.com/git/git/commit/cac5351363c5713248b8494e1e58e282c0a5bde7

I'm not sure about meaningless from a functionality perspective. All new
features are going into PCRE2. PCRE is a stable branched with only bug
fixes and security problems fixed. The newest features, including
performance improvements, are all in PCRE2. I believe the reason it is
"PCRE2-10" instead of "PCRE-10", is because of API changes, and the
opportunity to improve or fix previous API decisions. This then becomes the
basis for all future development free of the PCRE API shackles.



>
> Also, it looks like PCRE2 is still not supported even by Exim,
> which is the parent project of PCRE and PCRE2:
>
> https://bugs.exim.org/show_bug.cgi?id=1878


I don't think Exim should be the measure:

"PCRE was originally written for the Exim MTA <https://www.exim.org/>, but
is now used by many high-profile open source projects, including Apache
<https://httpd.apache.org/>, PHP <http://www.php.net/>, KDE
<https://www.kde.org/>, Postfix <http://www.postfix.org/>, and Nmap
<https://nmap.org/>. PCRE has also found its way into some well known
commercial products, like Apple Safari <https://www.apple.com/safari/>.
Some other interesting projects using PCRE include Chicken
<http://www.call-with-current-continuation.org/>, Ferite
<http://www.ferite.org/>, Onyx <http://www.canonware.com/onyx/>, Hypermail
<http://www.hypermail-project.org/>, Leafnode
<http://leafnode.sourceforge.net/>, Askemos <http://www.askemos.org/>,
Wenlin <http://www.wenlin.com/>, and 8th <http://8th-dev.com/>."

This list is also far from complete. PCRE and PCRE2 are widely used, and
PCRE2 is where all current improvement is occurring. Anybody waiting for
Exim, will probably be among the very last to switch.


As such, adding PCRE2 support to nginx looks premature.
>


Before writing the above, I was debating with myself about when the right
time to add support for a new component release is. For some projects and
some components, it will be more important than others. For example,
OpenSSL 1.1.1 with TLSv1.3 support might be considered premature for some
projects to support, and yet Nginx supports this newly released version
long before OpenSSL 1.1.1 is readily available in a majority of
distributions that you support. I think in this case, OpenSSL 1.1.1 is of
strategic importance to Nginx, and this ensured it was on the roadmap.
(However, it still seems to be missing an ability to configure the cipher
suite... :-) )

I don't know if PCRE2 belongs on this roadmap. I think there have been
significant improvements with the JIT compilation that could prove useful
for higher performance evaluation of regular expressions with Nginx, but I
personally don't have this requirement, so if after considering all of the
above - you still felt it was premature, I wouldn't raise any concern
personally. I just want to make sure this is an informed position. :-)

-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20180919/84038086/attachment.html>