Add option to configure http/s managed transport
This change introduces NewRegisterSmartTransportWithOptions() to help
configure the smart transport with SmartSubtransportOptions. If the
default smart subtransport client needs to be configured, a newly
configured smart transport can be registered and used.
The SmartSubtransportOptions includes CABundle only for now.
This enables creating and using new transport with secrets that can be deleted and not shared with subsequent operations.
The http client in httpSmartSubtransport is now shared with the
underlying httpSmartSubtransportStream, reusing the client and its
configurations.
It also fixes the error during cloning:
unable to clone: Post "http://test-user:***@127.0.0.1:40463/bar/test-reponame/git-upload-pack": io: read/write on closed pipe
by using credentials if available and avoiding failure due to unauthorized request.
A user of the smart transport who needs to add a CA bundle in the http client can do the following to setup the smart transport before cloning:
stOpts := &git2go.SmartSubtransportOptions{CABundle: opts.CAFile}
rst, err := git2go.NewRegisterSmartTransportWithOptions("https", stOpts)
if err != nil {
return err
}
if rst != nil {
defer rst.Free()
}
NOTE: This is a rewrite of the fix in #858 to avoid creating a global cert pool. Similar to #858, I would like to have some guidance in understanding if this implementation is the right approach and addressing any possible issues due to this change.
Refer #858 for background and more information about this change.
@darkowlzz if you replace req, err = http.NewRequest("POST", url+"/info/refs?service=git-receive-pack", nil) with req, err = http.NewRequest("POST", url+"/git-receive-pack", nil) everything works for me. Thank you very much for your work!
we're getting Post ...: io: read/write on closed pipe when fetching over https with basic auth, does this PR suggest it is not currently supported?
fwiw it was working on version v31.4.14
we're getting
Post ...: io: read/write on closed pipewhen fetching over https with basic auth, does this PR suggest it is not currently supported?
@tylerphelan I experienced the same and this PR is an attempt to fix that. It's documented in https://github.com/libgit2/git2go/pull/858 how I attempted to fix the closed pipe error. Do you get the same error with this fix? I thought I did test it with basic auth.
@darkowlzz worked for me, thanks for this PR!
Curious if this is going to be merged?