On 20 January 2015 at 14:15, Branko Čibej <br...@wandisco.com> wrote: > On 19.01.2015 18:10, Ivan Zhakov wrote: >> I've implemented proposed behavior in r1653032. >> >> On 18 January 2015 at 06:48, Daniel Shahaf <d...@daniel.shahaf.name> wrote: >>> It would be nice if the the logged message should be different in that >>> case, too. That is: there should be some indication, besides the >>> different log level, that the subrequest-generated log event is >>> "normal". >>> >>> That is, we don't want this: >>> >>> [debug] Access denied: /private >>> [error] Access denied: /private >>> >>> But this: >>> >>> [debug] Hiding directory '/private' (Access denied) >>> [error] Access denied: /private >>> >>> (Or some other log level instead of "debug" — I haven't thought about >>> what log level would be appropriate.) >> I agree that different log message would be nice to have, but there is >> an issue: in mod_authz_svn we're not 100% sure that path will be >> hidden. mod_authz_svn just answer the question whether access allowed >> or not, but it doesn't know how this information will be used latter >> at mod_dav_svn layer. May be different wording may fix this issue >> though. > > I'm confused: when/why would mod_dav_svn ignore the result of an authz > check? > I meant that hiding unreadable path is not only possible behavior for mod_dav_svn. For example it may error out if it got unreadable path. For example get-locks-report: attempt to get lock for unreadable path will result requested failure (subversion\mod_dav_svn\lock.c:470). IMO logging "Hiding path" will be confusing for user.
-- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
