On 10/12/07, ΠΠΈΠΊΠΎΠ»Π°ΠΉ ΠΠΎΠΌΡΡ
ΠΎΠ²ΡΠΊΠΈΠΉ <nick2005a.d@gmail.com> wrote:
> Hello.
> I have two hosts in my environment - one is production server with a
> lot of services running on it, second is a virtual machine with clear
> Debian Etch installation.
> On my production server I has some SVN (with DAV) configuration which
> partially works, to make it fully usable I need to perform some
> experiments and so I'm trying to make similar configuration on my
> testing machine,
>
> So, first I tried fully replicate server's config, but it wasn't work.
> Then I made simplest case - one repository with non-ASCII characters
> in it's path. So I have config like this:
>
> <VirtualHost test-svn.example.com:80>
> <Location />
> DAV svn
> SVNPath /var/www/some-non-ASCII-chars
> </Location>
> </VirtualHost>
>
> Also I add this string to /etc/envvars: LANG=ru_RU.UTF-8
>
>
> Then I restarted Apache and tried to access to my repository. And...
> Got an error! "can't convert from UTF-8 to native encoding"... But
> same configuration works on my production server... I tried a number
> of things and found solution!
>
> This configuration works only if mod_php5 loaded into Apache!!! What
> the ...? How mod_php5 can influence on mod_dav_svn? Or mod_php5
> somehow influence on Apache's internals? Can someone explain me such
> behaviour?
It can, for example if it were to change global application state by
using umask(), setlocale(), cwd(), etc. In this case, it's probably
setlocale().
mod_php[5]() is known for not behaving nicely in a multi-application
environment, changing signal handlers and other global state which
shouldn't be messed with in a library. Guess mod_php5() doesn't
consider itself a library...
Anyway, mod_php5() is known to influence the (correct) operation of mod_dav_svn.
HTH,
Erik.
Received on Fri Oct 12 22:21:31 2007