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
