Re: [PATCH 2/3] remote-curl: tighten "version 2" check for smart-http

On 2018.11.16 03:48, Jeff King wrote: > In a v2 smart-http conversation, the server should reply to our initial > request with a pkt-line saying "version 2" (this is the start of the > "capabilities advertisement"). We check for the string using > starts_with(), but that's overly permissive (it

Re: [PATCH 1/3] remote-curl: refactor smart-http discovery

On 2018.11.16 03:47, Jeff King wrote: > After making initial contact with an http server, we have to decide if > the server supports smart-http, and if so, which version. Our rules are > a bit inconsistent: > > 1. For v0, we require that the content-type indicates a smart-http > response.

Re: [PATCH 0/3] remote-curl smart-http discovery cleanup

On 2018.11.16 03:44, Jeff King wrote: [...] > Amusingly, this does break the test you just added, because it tries to > issue an ERR after claiming "text/html" (and after my patch, we > correctly fall back to dumb-http). Heh yeah, I copied the script from a dumb-http test without reading the

[PATCH 3/3] remote-curl: die on server-side errors

From: Josh Steadmon When a smart HTTP server sends an error message via pkt-line, remote-curl will fail to detect the error (which usually results in incorrectly falling back to dumb-HTTP mode). This patch adds a check in check_smart_http() for server-side error messages, as well as a test case

[PATCH 2/3] remote-curl: tighten "version 2" check for smart-http

In a v2 smart-http conversation, the server should reply to our initial request with a pkt-line saying "version 2" (this is the start of the "capabilities advertisement"). We check for the string using starts_with(), but that's overly permissive (it would match "version 20", for example). Let's

[PATCH 1/3] remote-curl: refactor smart-http discovery

After making initial contact with an http server, we have to decide if the server supports smart-http, and if so, which version. Our rules are a bit inconsistent: 1. For v0, we require that the content-type indicates a smart-http response. We also require the response to look vaguely like

[PATCH 0/3] remote-curl smart-http discovery cleanup

h, we correctly fall back to dumb-http). > If no one has any objections, I'll include the diff below in v2. Thanks > for the help Jeff! I think it makes sense to do the refactoring first as a separate step. And of course it needs a commit message. So how about this series (your original

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.14 02:00, Jeff King wrote: > On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote: > > > Yes, the packet_read_line_buf() interface will both advance the buf > > pointer and decrement the length. So if we want to "peek", we have to > > do so with a copy (there's a peek function if

Re: [PATCH] remote-curl: die on server-side errors

On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote: > Yes, the packet_read_line_buf() interface will both advance the buf > pointer and decrement the length. So if we want to "peek", we have to > do so with a copy (there's a peek function if you use the packet_reader > interface, but that

Re: [PATCH] remote-curl: die on server-side errors

On Tue, Nov 13, 2018 at 02:25:40PM -0800, Josh Steadmon wrote: > > The magic "4" here and in the existing "version 2" check is because we > > are expecting pkt-lines. The original conditional always calls > > packed_read_line_buf() and will complain if we didn't actually get a > > pkt-line. > >

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.13 23:30, Junio C Hamano wrote: > stead...@google.com writes: > > > When a smart HTTP server sends an error message via pkt-line, > > remote-curl will fail to detect the error (which usually results in > > incorrectly falling back to dumb-HTTP mode). >

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.13 09:26, Jeff King wrote: > On Mon, Nov 12, 2018 at 02:44:56PM -0800, stead...@google.com wrote: > > > When a smart HTTP server sends an error message via pkt-line, > > remote-curl will fail to detect the error (which usually results in > > incorrectly fallin

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.13 12:02, Junio C Hamano wrote: > stead...@google.com writes: > > > When a smart HTTP server sends an error message via pkt-line, > > remote-curl will fail to detect the error (which usually results in > > incorrectly falling back to dumb-HTTP mode). > &g

Re: [PATCH] remote-curl: die on server-side errors

stead...@google.com writes: > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). OK, that is a valid thing to worry about. > > This patch adds a check i

Re: [PATCH] remote-curl: die on server-side errors

On Mon, Nov 12, 2018 at 02:44:56PM -0800, stead...@google.com wrote: > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). > > This patch adds a check i

Re: [PATCH] remote-curl: die on server-side errors

stead...@google.com writes: > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). > > This patch adds a check in discover_refs() for server-side error >

Re: [PATCH] remote-curl: die on server-side errors

stead...@google.com writes: > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). > > This patch adds a check in discover_refs() for server-side error >

Re: [PATCH] remote-curl: die on server-side errors

On Mon, Nov 12, 2018 at 2:45 PM wrote: > > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). > > This patch adds a check in discover_refs() for

[PATCH] remote-curl: die on server-side errors

When a smart HTTP server sends an error message via pkt-line, remote-curl will fail to detect the error (which usually results in incorrectly falling back to dumb-HTTP mode). This patch adds a check in discover_refs() for server-side error messages, as well as a test case for this issue. Signed

[PATCH v4 3/4] fix curl version to support CURL_HTTP_VERSION_2TLS

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/http.c b/http.c index b2ec31aef5..86e454cff5 100644 --- a/http.c +++ b/http.c @@ -811,10 +811,10 @@ static CURL *get_curl_handle(void

[PATCH v3 3/4] fix curl version to support CURL_HTTP_VERSION_2TLS

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/http.c b/http.c index b2ec31aef5..86e454cff5 100644 --- a/http.c +++ b/http.c @@ -811,10 +811,10 @@ static CURL *get_curl_handle(void

[PATCH v2 3/3] fix curl version to support CURL_HTTP_VERSION_2TLS

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/http.c b/http.c index b2ec31aef5..86e454cff5 100644 --- a/http.c +++ b/http.c @@ -811,10 +811,10 @@ static CURL *get_curl_handle(void

Re: [PATCH v2] build: link with curl-defined linker flags

James Knight writes: > Changes v1 -> v2: > - Improved support for detecting curl linker flags when not using a > configure-based build (mentioned by Junio C Hamano). > - Adding a description on how to explicitly use the CURL_LDFLAGS > define when not using configure (

[PATCH v2] build: link with curl-defined linker flags

Adjusting the build process to rely more on curl-config to populate linker flags instead of manually populating flags based off detected features. Originally, a configure-invoked build would check for SSL-support in the target curl library. If enabled, NEEDS_SSL_WITH_CURL would be set and used

Re: [PATCH] build: link with curl-defined linker flags

James Knight writes: > Makefile | 21 +++-- > config.mak.uname | 5 ++--- > configure.ac | 17 +++-- > 3 files changed, 16 insertions(+), 27 deletions(-) > > diff --git a/Makefile b/Makefile > index b08d5ea25..c3be87b0e 100644 > --- a/Makefile > +++

[PATCH] build: link with curl-defined linker flags

Adjust the autotools configuration to populate libcurl-related linker flags from curl-config instead of manually populating flags based off detected features. Originally, the configuration would check for SSL-support in the target curl library. If enabled, NEEDS_SSL_WITH_CURL would be set

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

Johannes Schindelin writes: >> I did not and I do not think it would. I was wondering if the >> ability to be able to specify these per destination is something >> very useful and deserves to be called out in the doc, together with >> ... > > I do not think that it needs to be called out

Re: [PATCH] http: give curl version warnings consistently

Johannes Schindelin writes: > On Thu, 25 Oct 2018, Junio C Hamano wrote: > >> When a requested feature cannot be activated because the version of >> cURL library used to build Git with is too old, most of the codepaths >> give a warning like "$Feature is not s

Re: [PATCH] http: give curl version warnings consistently

Hi Junio, On Thu, 25 Oct 2018, Junio C Hamano wrote: > When a requested feature cannot be activated because the version of > cURL library used to build Git with is too old, most of the codepaths > give a warning like "$Feature is not supported with cURL < $Version", >

[PATCH v2 2/3] http: add support for disabling SSL revocation checks in cURL

From: Brendan Forster This adds support for a new http.schannelCheckRevoke config value. This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a rem

[PATCH v2 0/3] Allow choosing the SSL backend cURL uses (plus related patches)

d to be included in v2, but Junio came up with https://public-inbox.org/git/xmqqsh0uln5c.fsf...@gitster-ct.c.googlers.com/ in the meantime, which I like better. Brendan Forster (1): http: add support for disabling SSL revocation checks in cURL Johannes Schindelin (2): http: add support f

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

Hi Junio, On Thu, 18 Oct 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> In any case, you can use "http..$variable" to say "I want the > >> http.$variable to be in effect but only when I am talking to ". > >> Does it make sense for this new variable, too? That is, does it >

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

Hi Junio, On Thu, 25 Oct 2018, Junio C Hamano wrote: > Eric Sunshine writes: > > > On Mon, Oct 15, 2018 at 6:14 AM Brendan Forster via GitGitGadget > > wrote: > >> This config value is only used if http.sslBackend is set to "schannel", > >> wh

Re: [PATCH] http: give curl version warnings consistently

On Thu, Oct 25, 2018 at 12:29:19PM +0900, Junio C Hamano wrote: > When a requested feature cannot be activated because the version of > cURL library used to build Git with is too old, most of the codepaths > give a warning like "$Feature is not supported with cURL < $Version&qu

[PATCH] http: give curl version warnings consistently

When a requested feature cannot be activated because the version of cURL library used to build Git with is too old, most of the codepaths give a warning like "$Feature is not supported with cURL < $Version", marked for l10n. A few of them, however, did not follow that pattern and sai

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

Eric Sunshine writes: > On Mon, Oct 15, 2018 at 6:14 AM Brendan Forster via GitGitGadget > wrote: >> This config value is only used if http.sslBackend is set to "schannel", >> which forces cURL to use the Windows Certificate Store when validating >> server cer

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

Johannes Schindelin writes: >> In any case, you can use "http..$variable" to say "I want the >> http.$variable to be in effect but only when I am talking to ". >> Does it make sense for this new variable, too? That is, does it >> benefit the users to be able to do something like this? >> >>

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

On Tue, Oct 16, 2018 at 02:25:57PM +0200, Johannes Schindelin wrote: > > > That ">=" is hard to grok. I think you meant it to be pronounced > > > "requries at least", but that is not a common reading. People more > > > commonly pronounce it "is greater than or equal to". > > > > This seemed

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

> > > +#else > > > + warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options > > > because\n" > > > + "your curl version is too old (>= 7.44.0)"); > > > +#endif > > > > That ">="

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

m being picked up by mistake). If this explanation sounds obscure, the reason is that it *is* obscure. If you are truly interested in the details, I can point you to the relevant tickets on Git for Windows' bug tracker. > > +#if LIBCURL_VERSION_NUM >= 0x072c00 > > + cur

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

Hi Eric, On Mon, 15 Oct 2018, Eric Sunshine wrote: > On Mon, Oct 15, 2018 at 6:14 AM Brendan Forster via GitGitGadget > wrote: > > This config value is only used if http.sslBackend is set to "schannel", > > which forces cURL to use the Windows Certificate Stor

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

On Tue, Oct 16, 2018 at 01:23:25PM +0900, Junio C Hamano wrote: > > +#if LIBCURL_VERSION_NUM >= 0x072c00 > > + curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, > > CURLSSLOPT_NO_REVOKE); > > +#else > > + warning("CURLSSLOPT_NO_REVOKE not ap

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

t;= 0x072c00 > + curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, > CURLSSLOPT_NO_REVOKE); > +#else > + warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options > because\n" > + "your curl version is too old (>

Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

On Mon, Oct 15, 2018 at 6:14 AM Brendan Forster via GitGitGadget wrote: > This config value is only used if http.sslBackend is set to "schannel", > which forces cURL to use the Windows Certificate Store when validating > server certificates associated with a remote serve

[PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

From: Brendan Forster This adds support for a new http.schannelCheckRevoke config value. This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a rem

[PATCH 0/3] Allow choosing the SSL backend cURL uses (plus related patches)

checks in cURL Johannes Schindelin (2): http: add support for selecting SSL backends at runtime http: when using Secure Channel, ignore sslCAInfo by default Documentation/config.txt | 21 http.c | 71 +++- 2 files changed, 91

Re: [PATCH 2/2] remote-curl: remove spurious period

On Wed, Aug 8, 2018 at 4:52 AM Johannes Schindelin via GitGitGadget wrote: > > We should not interrupt. sentences in the middle. I love this. commit message. :-) ... > /* The client backend isn't giving us compressed data so > -* we can try to deflate it

[PATCH 2/2] remote-curl: remove spurious period

From: Johannes Schindelin We should not interrupt. sentences in the middle. Signed-off-by: Johannes Schindelin --- remote-curl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/remote-curl.c b/remote-curl.c index 99b0bedc6..fb28309e8 100644 --- a/remote-curl.c +++

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

I have curl 7.35.0 installed on my ubuntu14.04, version infos is as below I have recompiled git against openssl. the git version is 1.9.1. I encountered this error "error: git-remote-http died of signal 13" when I issue `git clone http://github.com/tensorflow/tensorflow.git`. Should

[PATCH v1 20/25] structured-logging: add structured logging to remote-curl

From: Jeff Hostetler remote-curl is not a builtin command and therefore, does not inherit the common cmd_main() startup in git.c Wrap cmd_main() with slog_cmd_main() in remote-curl to initialize logging. Add slog timers around push, fetch, and list verbs. Signed-off-by: Jeff Hostetler

RE: [PATCH 1/2] remote-curl: accept all encoding supported by curl

Hi Jonathan, I'd like to confirm, that your patch fixes my problem: I can sync with google repository now using git and curl version without gzip support. Do you know how this patch is going to be released? Just HEAD now and GA in the next planned release? Communication looks like follow now

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

On Wed, 23 May 2018, Junio C Hamano wrote: -> Accept-Encoding: gzip +> Accept-Encoding: ENCODINGS Is the ordering of these headers determined by the user of cURL library (i.e. Git), or whatever the version of cURL we happened to link with happens to produce? The point is whether the

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

On Wed, May 23, 2018 at 10:23:26AM +0900, Junio C Hamano wrote: > Similarly, how much control do we have to ensure that the test HTTPD > server (1) supports gzip and (2) does not support encoding algos > with confusing names e.g. "funnygzipalgo" that may accidentally > match that pattern? I feel

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

cat >exp < > GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1 > > Accept: */* > -> Accept-Encoding: gzip > +> Accept-Encoding: ENCODINGS > > Pragma: no-cache Is the ordering of these headers determined by the user of cURL library (i.e. Git), or what

Re: [PATCH v2 2/2] remote-curl: accept compressed responses with protocol v2

Brandon Williams wrote: > Configure curl to accept compressed responses when using protocol v2 by > setting `CURLOPT_ENCODING` to "", which indicates that curl should send > an "Accept-Encoding" header with all supported compression encodings. > > S

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Brandon Williams wrote: > Configure curl to accept all encodings which curl supports instead of > only accepting gzip responses. > > This fixes an issue when using an installation of curl which is built > without the "zlib" feature. Since aa90b9697 (Enable info/refs gzi

[PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Configure curl to accept all encodings which curl supports instead of only accepting gzip responses. This fixes an issue when using an installation of curl which is built without the "zlib" feature. Since aa90b9697 (Enable info/refs gzip decompression in HTTP client, 2012-09-19)

[PATCH v2 2/2] remote-curl: accept compressed responses with protocol v2

Configure curl to accept compressed responses when using protocol v2 by setting `CURLOPT_ENCODING` to "", which indicates that curl should send an "Accept-Encoding" header with all supported compression encodings. Signed-off-by: Brandon Williams <bmw...@google.com> -

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

ions. Thanks for the clarification. Sounds like the best option is to continue with this patch and let curl decide using "". > > I would agree that the libcurl setopt call should probably be made to fail > if asked to use a compression method not built-in/supported.

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

anymore. libcurl 7.45.0 is 2.5 years and 1500+ bug fixes old after all. My casual searches for a curl problem like this - fixed in 7.45.0 or later - also failed. -- / daniel.haxx.se

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45 , in this sequence of code. Please let me know. -- Sent from: http://git.661346.n2.nabble.com/

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

On Tue, 22 May 2018, curlUser wrote: Again SIGPIPE is seen with curl version 7.45.0 with multi interface. Backtrace shows : ... Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in disconnect_if_dead? Can anyone comment on this. I'm pretty sure this issue isn't present

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

Hi, Again SIGPIPE is seen with curl version 7.45.0 with multi interface. Backtrace shows : #7 0x7f141bea40cd in Curl_ossl_close (conn=0x7f14193f9848, sockindex=0) at vtls/openssl.c:881 #8 0x7f141bea8f54 in Curl_ssl_close (conn=0x7f14193f9848, sockindex=0) at vtls/vtls.c:527 #9

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

On Mon, 21 May 2018, Jonathan Nieder wrote: Looking at the code here, this succeeds if enough memory is available. There is no check if the given parameter is part of Curl_all_content_encodings(); By "this" are you referring to the preimage or the postimage? Are you suggesting a change in

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

Hi, Stefan Beller wrote: > On Mon, May 21, 2018 at 4:40 PM, Brandon Williams <bmw...@google.com> wrote: >> Configure curl to accept all encoding which curl supports instead of >> only accepting gzip responses. > > This partially reverts aa90b9697f9 (Enable info/refs g

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

On Mon, May 21, 2018 at 4:40 PM, Brandon Williams <bmw...@google.com> wrote: > Configure curl to accept all encoding which curl supports instead of > only accepting gzip responses. This partially reverts aa90b9697f9 (Enable info/refs gzip decompression in HTTP client

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

Hi, Brandon Williams wrote: > Subject: remote-curl: accept all encoding supported by curl nit: s/encoding/encodings > Configure curl to accept all encoding which curl supports instead of > only accepting gzip responses. Likewise. > This is necessary to fix a bug when using an

[PATCH 2/2] remote-curl: accept compressed responses with protocol v2

Configure curl to accept compressed responses when using protocol v2 by setting `CURLOPT_ENCODING` to "", which indicates that curl should send an "Accept-Encoding" header with all supported compression encodings. Signed-off-by: Brandon Williams <bmw...@google.com> -

[PATCH 1/2] remote-curl: accept all encoding supported by curl

Configure curl to accept all encoding which curl supports instead of only accepting gzip responses. This is necessary to fix a bug when using an installation of curl which doesn't support gzip. Since curl doesn't do any checking to verify that it supports the encoding set when calling

[PATCH 2/2] t5561: skip tests if curl is not available

It's possible to have libcurl installed but not the curl command-line utility. The latter is not generally needed for Git's http support, but we use it in t5561 for basic tests of http-backend's functionality. Let's detect when it's missing and skip this test. Note that we can't mark

[PATCH 1/2] t5561: drop curl stderr redirects

For a normal test run, stderr is already redirected to /dev/null by the test suite. When used with "-v", suppressing stderr is actively harmful, as it may hide the reason for curl failing. Reported-by: Jens Krüger <jens.krue...@frm2.tum.de> Signed-off-by: Jeff King <p...@pef

[PATCH 0/2] t5561 fails without curl installed

t; mode you > probably would have gotten a useful error like "curl: not found" > > - it's rare but possible to have libcurl installed (which is needed > for the server side, and what we key on for running the httpd tests) > but not the curl binary. This test

[PATCH v6 34/35] remote-curl: implement stateless-connect command

Teach remote-curl the 'stateless-connect' command which is used to establish a stateless connection with servers which support protocol version 2. This allows remote-curl to act as a proxy, allowing the git client to communicate natively with a remote end, simply using remote-curl as a pass

[PATCH v6 35/35] remote-curl: don't request v2 when pushing

In order to be able to ship protocol v2 with only supporting fetch, we need clients to not issue a request to use protocol v2 when pushing (since the client currently doesn't know how to push using protocol v2). This allows a client to have protocol v2 configured in `protocol.version` and take

[PATCH v6 29/35] remote-curl: create copy of the service name

Make a copy of the service name being requested instead of relying on the buffer pointed to by the passed in 'const char *' to remain unchanged. Currently, all service names are string constants, but a subsequent patch will introduce service names from external sources. Signed-off-by: Brandon

[PATCH v6 30/35] remote-curl: store the protocol version the server responded with

Store the protocol version the server responded with when performing discovery. This will be used in a future patch to either change the 'Git-Protocol' header sent in subsequent requests or to determine if a client needs to fallback to using a different protocol version. Signed-off-by: Brandon

[PATCH v5 30/35] remote-curl: store the protocol version the server responded with

Store the protocol version the server responded with when performing discovery. This will be used in a future patch to either change the 'Git-Protocol' header sent in subsequent requests or to determine if a client needs to fallback to using a different protocol version. Signed-off-by: Brandon

[PATCH v5 34/35] remote-curl: implement stateless-connect command

Teach remote-curl the 'stateless-connect' command which is used to establish a stateless connection with servers which support protocol version 2. This allows remote-curl to act as a proxy, allowing the git client to communicate natively with a remote end, simply using remote-curl as a pass

[PATCH v5 35/35] remote-curl: don't request v2 when pushing

In order to be able to ship protocol v2 with only supporting fetch, we need clients to not issue a request to use protocol v2 when pushing (since the client currently doesn't know how to push using protocol v2). This allows a client to have protocol v2 configured in `protocol.version` and take

[PATCH v5 29/35] remote-curl: create copy of the service name

Make a copy of the service name being requested instead of relying on the buffer pointed to by the passed in 'const char *' to remain unchanged. Currently, all service names are string constants, but a subsequent patch will introduce service names from external sources. Signed-off-by: Brandon

Re: [PATCH v4 35/35] remote-curl: don't request v2 when pushing

On Wed, 28 Feb 2018 15:22:52 -0800 Brandon Williams wrote: > In order to be able to ship protocol v2 with only supporting fetch, we > need clients to not issue a request to use protocol v2 when pushing > (since the client currently doesn't know how to push using protocol v2).

Re: [PATCH v4 29/35] remote-curl: create copy of the service name

On Wed, 28 Feb 2018 15:22:46 -0800 Brandon Williams wrote: > Make a copy of the service name being requested instead of relying on > the buffer pointed to by the passed in 'const char *' to remain > unchanged. > > Currently, all service names are string constants, but a

Re: [PATCH v4 34/35] remote-curl: implement stateless-connect command

uct proxy_state *p = userdata; > > + size_t avail = p->request_buffer.len - p->pos; > > + > > + > > + if (eltsize != 1) > > + BUG("curl read callback called with size = %zu != 1", eltsize); > > The format specified %z is not actually portabl

Re: [PATCH v4 34/35] remote-curl: implement stateless-connect command

eads, int for_push) > [...] > +static size_t proxy_in(char *buffer, size_t eltsize, > +size_t nmemb, void *userdata) > +{ > + size_t max; > + struct proxy_state *p = userdata; > + size_t avail = p->request_buffer.len - p->pos; > + > + > + if

[PATCH v4 30/35] remote-curl: store the protocol version the server responded with

Store the protocol version the server responded with when performing discovery. This will be used in a future patch to either change the 'Git-Protocol' header sent in subsequent requests or to determine if a client needs to fallback to using a different protocol version. Signed-off-by: Brandon

[PATCH v4 29/35] remote-curl: create copy of the service name

Make a copy of the service name being requested instead of relying on the buffer pointed to by the passed in 'const char *' to remain unchanged. Currently, all service names are string constants, but a subsequent patch will introduce service names from external sources. Signed-off-by: Brandon

[PATCH v4 34/35] remote-curl: implement stateless-connect command

Teach remote-curl the 'stateless-connect' command which is used to establish a stateless connection with servers which support protocol version 2. This allows remote-curl to act as a proxy, allowing the git client to communicate natively with a remote end, simply using remote-curl as a pass

[PATCH v4 35/35] remote-curl: don't request v2 when pushing

In order to be able to ship protocol v2 with only supporting fetch, we need clients to not issue a request to use protocol v2 when pushing (since the client currently doesn't know how to push using protocol v2). This allows a client to have protocol v2 configured in `protocol.version` and take

Re: [PATCH v3 34/35] remote-curl: implement stateless-connect command

On 02/27, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > > Teach remote-curl the 'stateless-connect' command which is used to > > establish a stateless connection with servers which support protocol > > version 2. This allows remote-curl to ac

Re: [PATCH v3 34/35] remote-curl: implement stateless-connect command

Hi, Brandon Williams wrote: > Teach remote-curl the 'stateless-connect' command which is used to > establish a stateless connection with servers which support protocol > version 2. This allows remote-curl to act as a proxy, allowing the git > client to communicate natively with

Re: [PATCH v3 31/35] remote-curl: store the protocol version the server responded with

Brandon Williams wrote: > Store the protocol version the server responded with when performing > discovery. This will be used in a future patch to either change the > 'Git-Protocol' header sent in subsequent requests or to determine if a > client needs to fallback to using a different protocol

Re: [PATCH v3 35/35] remote-curl: don't request v2 when pushing

On 02/22, Brandon Williams wrote: > On 02/21, Jonathan Tan wrote: > > On Tue, 6 Feb 2018 17:13:12 -0800 > > Brandon Williams wrote: > > > > > +test_expect_success 'push with http:// and a config of v2 does not > > > request v2' ' > > > + # Till v2 for push is designed, make

Re: [PATCH v3 35/35] remote-curl: don't request v2 when pushing

On 02/21, Jonathan Tan wrote: > On Tue, 6 Feb 2018 17:13:12 -0800 > Brandon Williams wrote: > > > +test_expect_success 'push with http:// and a config of v2 does not request > > v2' ' > > + # Till v2 for push is designed, make sure that if a client has > > + #

Re: [PATCH v3 30/35] remote-curl: create copy of the service name

On 02/21, Jonathan Tan wrote: > On Tue, 6 Feb 2018 17:13:07 -0800 > Brandon Williams wrote: > > > Make a copy of the service name being requested instead of relying on > > the buffer pointed to by the passed in 'const char *' to remain > > unchanged. > > > > Signed-off-by:

Re: [PATCH v3 35/35] remote-curl: don't request v2 when pushing

On Tue, 6 Feb 2018 17:13:12 -0800 Brandon Williams wrote: > +test_expect_success 'push with http:// and a config of v2 does not request > v2' ' > + # Till v2 for push is designed, make sure that if a client has > + # protocol.version configured to use v2, that the

Re: [PATCH v3 30/35] remote-curl: create copy of the service name

On Tue, 6 Feb 2018 17:13:07 -0800 Brandon Williams wrote: > Make a copy of the service name being requested instead of relying on > the buffer pointed to by the passed in 'const char *' to remain > unchanged. > > Signed-off-by: Brandon Williams Probably

Re: [PATCH 2/2] remote-curl: unquote incoming push-options

On 02/19, Jeff King wrote: > The transport-helper protocol c-style quotes the value of > any options passed to the helper via the "option " > directive. However, remote-curl doesn't actually unquote the > push-option values, meaning that we will send the quoted >

[PATCH 2/2] remote-curl: unquote incoming push-options

The transport-helper protocol c-style quotes the value of any options passed to the helper via the "option " directive. However, remote-curl doesn't actually unquote the push-option values, meaning that we will send the quoted version to the other side (whereas git-over-ssh would se

[PATCH v3 30/35] remote-curl: create copy of the service name

Make a copy of the service name being requested instead of relying on the buffer pointed to by the passed in 'const char *' to remain unchanged. Signed-off-by: Brandon Williams --- remote-curl.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH v3 31/35] remote-curl: store the protocol version the server responded with

Store the protocol version the server responded with when performing discovery. This will be used in a future patch to either change the 'Git-Protocol' header sent in subsequent requests or to determine if a client needs to fallback to using a different protocol version. Signed-off-by: Brandon

  1   2   3   4   5   >