Paul Hammant wrote on Sat, 09 Dec 2017 21:54 -0500:
> > The cause of the 403 should be logged on the server side.
> > It was:
> > [Sat Dec 09 22:24:47.803767 2017] [authz_svn:error] [pid 13] [client
> > 172.17.0.1:35066] Failed to load the mod_authz_svn config: Section name
> > '/foo/a/' contains non-canonical fspath '/foo/a/'
> > [Sat Dec 09 22:24:47.803817 2017] [authz_svn:error] [pid 13] [client
> > 172.17.0.1:35066] Access denied: 'harry' GET foo:/a
> Should an unparsable authz file be communicated in a clearer way than some
> URLs working and some 403ing?
Last I checked, that's not the failure mode. When the authz file fails
to parse, *all* accesses to the repository result in 403. That's true
even if the file parses correctly insofar as the .ini ConfigParser
format is concerned, but isn't a valid authz file for other reasons
(e.g., non- canonical paths in section headers).
> Should I raise this in https://issues.apache.org/jira/browse/SVN
> or not ?
We could clarify the error message by having it refer the admin to the
server log. We might also have the error message state "The authz file
failed to parse" (without details; we'd consider the authz file's path
and section names to be confidential).
Is that what you had in mind? Or are you thinking of a larger change,
e.g., detecting the invalid authz file even before a request is made to
a repository that uses it (= the invalid authz file)?
Received on 2017-12-10 05:16:57 CET