Issue #233: git clone https://... gives empty reply from server
| Reported by: | Michael Jünger |
| State: | new |
| Created on: | 2016-07-15 06:54 |
| Updated on: | 2016-07-16 21:42 |
Description
Hi,
Just for a quick overview: I have installed kallithea without using a virtualenv and installed it globally via pip on debian 7. I followed the steps to setup kallithea as described here: Setup instructions I am using nginx and used the example configuration file from there: Example configuration I ran 'paster serve my.ini'
So far kallithea is working and I was able to create a repository named Test through the web interface.
If I now try to clone my newly created repo using this command: git clone https://user@domain.tld/Test
I get the following error: fatal: unable to access 'https://user@domain.tld/Test/': Empty reply from server
I commented out the gist part in the nginx file and put the proxy settings directly into it but that are all differences to the example.
I am simply something missing in the nginx config file what is not mentioned in the example or may this be a bug?
Thank you much for any help.
Kind regards,
Michael Jünger
Attachments
Comments
Comment by Mads Kiilerich, on 2016-07-15 13:20
Does it work with http directly to paster serve?
Comment by Michael Jünger, on 2016-07-16 21:18
Hi,
it worked with http directly and meanwhile I found the cause of the problem for https connections.
As mentioned there: Debian Bug report logs it is because of this option in nginx: ssl_session_cache shared:SSL:10m; It is not set in the nginx config of kallithea but set in other site configurations. If I disable this option in every virtual host where it is set, I am able to clone my repos.
Obviously it is not a bug of kallithea directly but of curl.
Kind regards,
Michael
Comment by Mads Kiilerich, on 2016-07-16 21:42
This supports my opinionated opinion of strongly advising against using nginx for Kallithea. There are so many pitfalls and no benefits ... unless you happen to already be an nginx expert.