[vcs] Passing wrong content length header to subversion client.
We are proxying the SVN request to apache. If we get the apache response it may be compressed. The python requests library handles the decompression automatically for us. But when creating our response which is sent to the SVN client we are reusing the headers from the apache response. These headers contain the Content-Length from the compressed content but that is not correct because we are returning the uncompressed content in out response.
In most cases this only leads to a warning because actual length is bigger than Content-Length header says. This seems to be ignored by the SVN client. But there are also cases where the compressed length is greater than the decompressed length. I think this only happens for very small contents. But that leads to an error in the SVN client which complains about a truncated response from server. Even more confusing the behaviour of svn 1.8 and 1.9 slightly differs at this point. svn 1.9 seems to also tolerate the too short content at first but then it seems to truncate the content and it fails later on when trying to parse the xml
#2 Updated by Martin Bornhold about 4 years ago
- Status changed from In Progress to Resolved