HTTP to HTTPS redirect causes issues with credential handling.

[RaeveNoir]

We have a Gitlab omnibus install on an arbitrary port being served by a Haproxy on 80/443 splitting traffic by subdomain. LFS was then enabled in Gitlab and stores on a network mount. Credentials are supplied by LDAP, including SSH key support. Our SSL certs are supplied by Letsencrypt.

Haproxy was initially configured to redirect http scheme to https.

Attempting to push lfs files would work for about 35 seconds (regardless of source or ping) and then fail, reporting File Already Closed for all remaining transfers. This was while using SSH with keys. I'm mildly aware that lfs uses an http(s) connection in the background when using SSH for git.

After fiddling with timeouts and cache sizes for a while, in both Haproxy and Gitlab's nginx implementation, I instead found that eliminating the http->https redirect in Haproxy solved our issue, and lfs was happy to move half a gig at once.

I'm mostly concerned that some credential handling isn't sticking to using https, or doesn't support it in the first place.

[ttaylorr]

Hi @Ranzear, thank for opening this issue and I'm sorry that you're having trouble! Let's figure out what is going on.

I'm mostly concerned that some credential handling isn't sticking to using https, or doesn't support it in the first place.

Could you rerun the command with the http->https redirect enabled and GIT_TRACE=1 as well as GIT_CURL_VERBOSE=1 in your environment? If you could post the output here, making sure to remove any sensitive information, that would be helpful in tracking this down.

I looked at an issue similar to this a while ago in git-lfs/git-lfs#2235, wherein I taught Git LFS to copy credentials in a http->https redirection (sharing the same host), so that patch might be relevant to our discussion here.

[RaeveNoir]

https://gist.github.com/Ranzear/22a6ca6d4f85fb2f8618c36c68fbcc0c

So that's interesting. Nothing to do with credentials thankfully. (Title change inbound?)

It would seem to me that 301s are being counted against retries, even though they do seem to put data through. It's also horrendously slower, owing to extra requests per chunk. Each chunk gets 301'd and counts as a retry until it hits max retries and gives up. I can try with git config lfs.transfer.maxretries 1 and it fails out fairly immediately, while ~1000 gets a fair way's along (at about 1/10th upload speed however.)

[RaeveNoir]

(I appear to have ended up in the wrong issue tracker anyway.)