Re: Bug: invalid headers for git over http
Hi, Thanks for your quick response. That bug is something I missed when porting to py3. Apparently, other Git implementations are less strict, and it didn't come up while testing. Yes, i noticed that too. had to try hard to reproduce this. But I think the fix can be made simpler and more complete: https://kallithea-scm.org/repos/kallithea-incoming/changeset/b9be708625087a6618240d614d27782632a80b2b Can you confirm this works as well for you? Yes it does work and i agree it is a better solution. Cheers, Valentin On 10/28/20 2:13 PM, Valentin wrote: Hi, I've noticed cases in which kallithea returns headers that seem incorrect on git requests over http. This first occurred as some users had problems fetching repos from our kallithea instance with software that uses the JGit library on Windows (user agent string: JGit/5.4.2.201908231537-r). The error message noted: 'git fetch' command failed (repository dir: dir>/system/caches/git/git-233054F9.git). stderr: https:: expected Content-Type application/x-git-upload-pack-result; received Content-Type application/x-b'git-upload-pack'-result I was able to reproduce this header by using git for windows, although it didn't produce an error: valentin@CASHEW MINGW64 ~ $ GIT_CURL_VERBOSE=1 git clone https: Cloning into 'master'... ... ... 12:14:51.522612 http.c:721 <= Recv header, 59 bytes (0x003b) 12:14:51.522612 http.c:733 <= Recv header: Content-Type: application/x-git-upload-pack-advertisement ... ... 12:15:32.147657 http.c:721 <= Recv header, 55 bytes (0x0037) 12:15:32.147657 http.c:733 <= Recv header: Content-Type: application/x-b'git-upload-pack'-result The problem arises in pygrack.py [0] where encode('utf-8') is used on line 178: resp.content_type = 'application/x-%s-result' % git_command.encode('utf-8') in contrary, on line 128 str() is used: resp.content_type = 'application/x-%s-advertisement' % str(git_command) I patched my kallithea instance to use str() (see the attached diff) which resolves the problem. I think this is safe to do, as git_command is checked against valid commands before and therefor must be convertible to a string. Hope i got that right and you can integrate this into an upcoming release. Cheers, Valentin [0] https://kallithea-scm.org/repos/kallithea/files/855b37d3bacdc6175566ca7d23c19e2352da1087/kallithea/lib/middleware/pygrack.py ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: Bug: invalid headers for git over http
Hi Thanks for reporting ... and for the proposed fix. That bug is something I missed when porting to py3. Apparently, other Git implementations are less strict, and it didn't come up while testing. But I think the fix can be made simpler and more complete: https://kallithea-scm.org/repos/kallithea-incoming/changeset/b9be708625087a6618240d614d27782632a80b2b Can you confirm this works as well for you? /Mads On 10/28/20 2:13 PM, Valentin wrote: Hi, I've noticed cases in which kallithea returns headers that seem incorrect on git requests over http. This first occurred as some users had problems fetching repos from our kallithea instance with software that uses the JGit library on Windows (user agent string: JGit/5.4.2.201908231537-r). The error message noted: 'git fetch' command failed (repository dir: dir>/system/caches/git/git-233054F9.git). stderr: https:: expected Content-Type application/x-git-upload-pack-result; received Content-Type application/x-b'git-upload-pack'-result I was able to reproduce this header by using git for windows, although it didn't produce an error: valentin@CASHEW MINGW64 ~ $ GIT_CURL_VERBOSE=1 git clone https: Cloning into 'master'... ... ... 12:14:51.522612 http.c:721 <= Recv header, 59 bytes (0x003b) 12:14:51.522612 http.c:733 <= Recv header: Content-Type: application/x-git-upload-pack-advertisement ... ... 12:15:32.147657 http.c:721 <= Recv header, 55 bytes (0x0037) 12:15:32.147657 http.c:733 <= Recv header: Content-Type: application/x-b'git-upload-pack'-result The problem arises in pygrack.py [0] where encode('utf-8') is used on line 178: resp.content_type = 'application/x-%s-result' % git_command.encode('utf-8') in contrary, on line 128 str() is used: resp.content_type = 'application/x-%s-advertisement' % str(git_command) I patched my kallithea instance to use str() (see the attached diff) which resolves the problem. I think this is safe to do, as git_command is checked against valid commands before and therefor must be convertible to a string. Hope i got that right and you can integrate this into an upcoming release. Cheers, Valentin [0] https://kallithea-scm.org/repos/kallithea/files/855b37d3bacdc6175566ca7d23c19e2352da1087/kallithea/lib/middleware/pygrack.py ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Bug: invalid headers for git over http
Hi, I've noticed cases in which kallithea returns headers that seem incorrect on git requests over http. This first occurred as some users had problems fetching repos from our kallithea instance with software that uses the JGit library on Windows (user agent string: JGit/5.4.2.201908231537-r). The error message noted: 'git fetch' command failed (repository dir: dir>/system/caches/git/git-233054F9.git). stderr: https:: expected Content-Type application/x-git-upload-pack-result; received Content-Type application/x-b'git-upload-pack'-result I was able to reproduce this header by using git for windows, although it didn't produce an error: valentin@CASHEW MINGW64 ~ $ GIT_CURL_VERBOSE=1 git clone https: Cloning into 'master'... ... ... 12:14:51.522612 http.c:721 <= Recv header, 59 bytes (0x003b) 12:14:51.522612 http.c:733 <= Recv header: Content-Type: application/x-git-upload-pack-advertisement ... ... 12:15:32.147657 http.c:721 <= Recv header, 55 bytes (0x0037) 12:15:32.147657 http.c:733 <= Recv header: Content-Type: application/x-b'git-upload-pack'-result The problem arises in pygrack.py [0] where encode('utf-8') is used on line 178: resp.content_type = 'application/x-%s-result' % git_command.encode('utf-8') in contrary, on line 128 str() is used: resp.content_type = 'application/x-%s-advertisement' % str(git_command) I patched my kallithea instance to use str() (see the attached diff) which resolves the problem. I think this is safe to do, as git_command is checked against valid commands before and therefor must be convertible to a string. Hope i got that right and you can integrate this into an upcoming release. Cheers, Valentin [0] https://kallithea-scm.org/repos/kallithea/files/855b37d3bacdc6175566ca7d23c19e2352da1087/kallithea/lib/middleware/pygrack.py diff -r 855b37d3bacd kallithea/lib/middleware/pygrack.py --- a/kallithea/lib/middleware/pygrack.py Mon Oct 05 20:43:59 2020 +0200 +++ b/kallithea/lib/middleware/pygrack.py Wed Oct 28 14:08:19 2020 +0100 @@ -175,7 +175,7 @@ update_server_info(repo._repo) resp = Response() -resp.content_type = 'application/x-%s-result' % git_command.encode('utf-8') +resp.content_type = 'application/x-%s-result' % str(git_command) resp.charset = None resp.app_iter = out return resp ___ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general