Indeed, this was an issue, after removing AddEncoding directives it works now! Thank you. They were in my config on global level (<IfModule> context ) for a long time since Apache 1.3.x maybe.
It will be very good to add a note to the documentation about this issue here: https://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap And probably here too: http://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html It maybe a better way is not to remove them on global level and stick to each Directory except SVN's one but use RemoveEncoding on SVN location like this: <Location /svn>> ... RemoveEncoding .gz RemoveEncoding .Z </Location> 2014/1/10 Ben Reser <b...@reser.org> > On 1/9/14, 4:26 PM, Ben Reser wrote: > > What's happening is your httpd server is configured to add the gzip > encoding to > > the headers of files being served that have filenames that end in .gz. > > > > Typically you'll see that setup on the server with something like this: > > AddEncoding x-gzip .gz > > AddEncoding x-compress .Z > > > > AddEncoding is part of mod_mime and is documented here: > > https://httpd.apache.org/docs/current/mod/mod_mime.html#addencoding > > > > Those sorts of configurations should never apply to the Location being > used to > > serve Subversion. > > Realized after sending I may not have been as clear as I should have been. > > AddEncoding inserts a Content-Encoding header that specifies that the file > is > gziped without changing the content of the body. The Subversion client > decompresses the file but then realizes that it doesn't match the checksum > it > expected and issues an error. > > The purpose of the configuration option is to store pre-compressed files on > disk that are served to clients that can support gzip Content-Encoding > without > needing to do the compression in real time while the client decompresses > the > content on its end and uses it seamlessly. >
