Project

General

Profile

Bug #4112

[vcs] Passing wrong content length header to subversion client.

Added by Martin Bornhold about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
21.07.2016
Due date:
% Done:

0%

Estimated time:
Sorting:
Commit Number:
Affected Version:

Description

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

History

#1 Updated by Martin Bornhold about 4 years ago

  • Status changed from New to In Progress

Fixed it by ignoring the content length header when creating our response.

#2 Updated by Martin Bornhold about 4 years ago

  • Status changed from In Progress to Resolved

#3 Updated by Martin Bornhold about 4 years ago

  • Status changed from Resolved to Closed

Done and merged.

Also available in: Atom PDF