On Fri, Apr 19, 2024 at 3:32 PM BK <b...@gmx.de> wrote: > If the parser behaves like this in version 1.14, I take it as a given. > I would be interested to know the reasons for this change? > The parsing change was actually made in 1.10. It was done in order to implement "wildcarding" in path-based AuthZ [0]. Background [1], additional information [2].
tl;dr: With the implementation of wildcarding the ordering of the sections in the AuthZ file have become critical. Also note: as of SVN 1.10 the parsing of the AuthZ file now takes longer. Small AuthZ files won't likely see the issue but large AuthZ files can cause user-visible delays from Apache/svnserve. The workaround I've been using is to break up the single "super" AuthZ files into per-repository AuthZ files and use the Apache "AuthzSVNReposRelativeAccessFile" directive (see example 4 in [3]). > From the per repository point of view it didn't really help the clarity. > But maybe there are more important reasons for the change. > I hope the above helps. Cheers. Doug -- [0] https://subversion.apache.org/docs/release-notes/1.10.html#authzperf [1] https://cwiki.apache.org/confluence/display/SVN/Authz+Improvements [2] https://svn.haxx.se/dev/archive-2017-02/att-0188/ [3] https://svn.apache.org/repos/asf/subversion/branches/1.10.x/subversion/mod_authz_svn/INSTALL > Unfortunately, I don't have the expertise > or sufficient programming knowledge to submit a patch. > > Best Regards, > Bernhard > > > Am 18.04.24 um 10:28 schrieb Daniel Sahlberg: > > The code as it is now seems to be very intentionally written to NOT allow > multiple sections with the same name, see the check_open_section() function > in authz_parse.c[1]. > > I don't know if it would be possible to relax this restriction but feel > free to take a look at the code and send a patch to > d...@subversion.apache.org. > > It is not possible to switch back to the old authz parse code in version > 1.14. > > Kind regards, > Daniel > > -- *Doug Robinson* Senior Product Manager P +1 925 396 1125 *E* doug.robin...@cirata.com -- THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED If this message was misdirected, Cirata Ltd. and its subsidiaries, ("Cirata") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of Cirata, unless the author is authorized by Cirata to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by Cirata. Although Cirata operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.