Re: [PATCH v2] Added Curl Option to Override Request Method v2
- From
Drew Green <agreenbhm@gmail.com>
- Date
- Apr 26, 2022, 23:34 UTC
- Message-ID
- <CANDN8xGh31E3VwgRUb6YgFuswiyYjzJwK-tyvmo2c6KY+pOtJA@mail.gmail.com>
- In-Reply-To
- <YmhkCAbmNE8A7Wqy@camp.crustytoothpaste.net>
On Tue, Apr 26, 2022 at 7:30 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:
Show 33 quoted lines
> > On 2022-04-26 at 15:57:39, Drew Green via GitGitGadget wrote: > > From: agreenbhm <agreenbhm@gmail.com> > > > > Added support for environment variable "CURLOPT_CUSTOMREQUEST" > > and config option "http.customrequest" to allow setting the Curl > > option to override the default request method used by HTTP Git > > operations. Primary reason for this is to allow support for > > cloning repositories where only GET requests > > are allowed by a local web proxy but not POSTs. When cloning > > a repo first a GET is made to the server and then a > > POST is made to the "git-upload-pack" endpoint. In some > > corporate environments with strong controls > > only GET requests are allowed to known repository hosts (such > > as GitHub) through a web proxy to prevent data leakage. Using this > > new setting, a user can set the "CURLOPT_CUSTOMREQUEST=GET" env at runtime > > or "http.customrequest = GET" in their config file which will > > change the second request from a POST to a GET, bypassing > > web proxy restrictions on the type of requests allowed. > > Tested with GitHub, changing the request from POST to GET still > > results in the expected behavior of the repo successfully being cloned. > > I don't think this is a good idea. It may happen that GitHub or other > servers happen to accept a GET request here, but that is a bug and > should be fixed. It is definitely not something we should depend on or > rely on, and it isn't a documented part of the protocol. > > If your corporate environment doesn't allow POST requests, you may wish > to use SSH for Git operations instead, or you may need to explain to > your company why you cannot do your job with their proxy in place. > -- > brian m. carlson (he/him or they/them) > Toronto, Ontario, CA
Brian - I understand what you're saying, however I don't think adding this feature is detrimental in any way. It is simply leveraging a feature of curl without any promises of resulting behavior. Why not allow users to take advantage of a library feature if it can help?
-- Drew Green www.drewgreen.net PGP: 17BDDD7E