Source: libvmod-re2
Maintainer: Vinyl Cache Package Maintainers <team+varnish-team@tracker.debian.org>
Uploaders:
 Michael Fladischer <fladi@debian.org>,
 Marco d'Itri <md@linux.it>,
Section: web
Build-Depends:
 architecture-is-64-bit,
 autoconf-archive,
 debhelper-compat (= 13),
 libre2-dev,
 libvinylapi-dev,
 pkgconf,
 python3-docutils,
 vinyl-cache,
Standards-Version: 4.7.4.1
Vcs-Browser: https://salsa.debian.org/varnish-team/libvmod-re2
Vcs-Git: https://salsa.debian.org/varnish-team/libvmod-re2.git
Homepage: https://code.uplex.de/uplex-varnish/libvmod-re2

Package: libvmod-re2
Architecture: any
Depends:
 ${misc:Depends},
 ${shlibs:Depends},
Description: RE2 regular expressions for Vinyl Cache
 Vinyl Cache Module (VMOD) for access to the Google RE2 regular expression
 engine. Vinyl Cache VCL uses the PCRE library (Perl Compatible Regular
 Expressions) for its native regular expressions, which runs very
 efficiently for many common uses of pattern matching in VCL, as attested
 by years of successful use of PCRE with Vinyl Cache.
 .
 But for certain kinds of patterns, the worst-case running time of the
 PCRE matcher is exponential in the length of the string to be matched.
 The matcher uses backtracking, implemented with recursive calls to the
 internal match() function. In principle there is no upper bound to the
 possible depth of backtracking and recursion, except as imposed by the
 varnishd runtime parameters pcre_match_limit and
 pcre_match_limit_recursion; matches fail if either of these limits are
 met. Stack overflow caused by deep backtracking has occasionally been
 the subject of varnishd issues.
 .
 RE2 differs from PCRE in that it limits the syntax of patterns so that
 they always specify a regular language in the formally strict sense.
 Most notably, backreferences within a pattern are not permitted, for
 example (foo|bar)\1 to match foofoo and barbar, but not foobar
 or barfoo. See the link in SEE ALSO for the specification of RE2
 syntax.
 .
 This means that an RE2 matcher runs as a finite automaton, which
 guarantees linear running time in the length of the matched string.
 There is no backtracking, and hence no risk of deep recursion or stack
 overflow.
