"brian m. carlson" writes:
> Yeah, my default editor configuration for AsciiDoc is two spaces. I
> noticed that Junio's already picked it up for next, but I'll send a v2
> with this fixed in case he wants to merge the fixed version to master
> instead.
>
> If it's more convenient, I can send a f
When pushing more than one reference with the --atomic option, the
server is supposed to perform a single atomic transaction to update the
references, leaving them either all to succeed or all to fail. This
works fine when pushing locally or over SSH, but when pushing over HTTP,
we fail to pass th
On 2019-10-15 at 16:40:29, Jeff King wrote:
> On Tue, Oct 15, 2019 at 01:07:59AM +, brian m. carlson wrote:
> > diff --git a/Documentation/gitremote-helpers.txt
> > b/Documentation/gitremote-helpers.txt
> > index a5c3c04371..670d72c174 100644
> > --- a/Documentation/gitremote-helpers.txt
> > +
On Tue, Oct 15, 2019 at 01:07:59AM +, brian m. carlson wrote:
> Fix this by passing the option from the transport code through to remote
> helpers, and from the HTTP remote helper down to send-pack. With this
> change, we can detect if the server side rejects the push and report
> back approp
When pushing more than one reference with the --atomic option, the
server is supposed to perform a single atomic transaction to update the
references, leaving them either all to succeed or all to fail. This
works fine when pushing locally or over SSH, but when pushing over HTTP,
we fail to pass th
Use argv_array to build an array of strings instead of open-coding it.
This simplifies the code a bit.
We also need to make the specs parameter of push(), push_dav() and
push_git() const to match the argv member of the argv_array. That's
fine, as all three only actually read from the specs array
m(a, xmalloc, free, \
> + xrealloc, xstrdup, xcalloc)
> #endif
Yup. That looks better.
If your curl version is recent enough (which presumably is true for
most people these days), the entire #if/#endif block is skipped
while scanning for #else or #elif and #elseif willq be silently
ignored
f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds,
2009-05-31) never told cURL about it.
Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when
Carlo Marcelo Arenas Belón writes:
> +#elseif LIBCURL_VERSION_NUM >= 0x070c00
#elif
> +#define curl_global_init(a) curl_global_init_mem(a, xmalloc, free, \
> + xrealloc, xstrdup, xcalloc)
> #endif
>
> #if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBC
f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
never told cURL about it.
Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when
Carlo Marcelo Arenas Belón writes:
> f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
> never told cURL about it.
>
> Correct that by using the cURL initializer available since version 7.12 to
> point to xmalloc and friends for consistency which the
f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
never told cURL about it.
Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when
On Tue, Aug 13, 2019 at 10:00:44PM +0200, Johannes Schindelin wrote:
> > Jeff King writes:
> >
> > > I think it might be worth just eliminating the whole idea.
> >
> > I kinda like the simplification ;-) An even thinner wrapper that
> > calls malloc() and dies if it gets NULL, without any "try-to
Hi,
On Mon, 12 Aug 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think it might be worth just eliminating the whole idea.
>
> I kinda like the simplification ;-) An even thinner wrapper that
> calls malloc() and dies if it gets NULL, without any "try-to-free"
> logic.
This is one of t
On Mon, Aug 12, 2019 at 01:04:55PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think it might be worth just eliminating the whole idea.
>
> I kinda like the simplification ;-) An even thinner wrapper that
> calls malloc() and dies if it gets NULL, without any "try-to-free"
> logic.
Jeff King writes:
> I think it might be worth just eliminating the whole idea.
I kinda like the simplification ;-) An even thinner wrapper that
calls malloc() and dies if it gets NULL, without any "try-to-free"
logic.
On Sun, Aug 11, 2019 at 12:08:53PM -0700, Carlo Arenas wrote:
> there is also the risk that xmalloc might not be sufficiently thread
> safe (ex: when it triggers unuse_one_window() through the use of a
> try_to_free_routine in packfile.c but we could mitigate the risk for
> now by doing it only fi
Hi Carlo,
On Sun, 11 Aug 2019, Carlo Arenas wrote:
> On Sun, Aug 11, 2019 at 4:20 AM Johannes Schindelin
> wrote:
> > On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> > > cURL is very strict about its allocator being thread safe and so that
> > > might
On Sun, Aug 11, 2019 at 4:20 AM Johannes Schindelin
wrote:
> On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> > cURL is very strict about its allocator being thread safe and so that might
> > be an issue to look for.
>
> Looks good to me.
it is not ready yet for usi
Hi,
On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> 4a30976e28 ([PATCH] support older versions of libcurl, 2005-07-28) added
> support for conditionally initializing cURL but when f0ed8226c9
> (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31) that
> su
On Sat, Aug 10, 2019 at 3:17 PM Daniel Stenberg wrote:
>
> On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
>
> > tested in macOS 10.14.6 with the system provided cURL (7.54.0)
> > and latest (7.65.3) and while the API used should be added starting around
> > 7.
On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
tested in macOS 10.14.6 with the system provided cURL (7.54.0)
and latest (7.65.3) and while the API used should be added starting around
7.12.0 (mid 2014).
Let me just gently point out that 7.12.0 was relased mid *2004*, see
https
4a30976e28 ([PATCH] support older versions of libcurl, 2005-07-28) added
support for conditionally initializing cURL but when f0ed8226c9
(Add custom memory allocator to MinGW and MacOS builds, 2009-05-31) that
support wasn't updated to make sure cURL will use the same allocator than
g
From: Philip Oakley
Upon seeing the '-lcurl' option, point to the libcurl.lib.
While there, fix the elsif indentation.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
contrib/buildsystems/engine.pl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/con
On Tue, Jul 23, 2019 at 07:43:01PM +, Raitanen, Adam wrote:
> Yes there is a config.mak.autogen and it does not have an entry for
> CURL_CONFIG, although it has a correct entry for CURLDIR.
>
> The config.log also shows it checking for curl-config and not finding it then
Yes there is a config.mak.autogen and it does not have an entry for
CURL_CONFIG, although it has a correct entry for CURLDIR.
The config.log also shows it checking for curl-config and not finding it then
proceeding anyway:
configure:5917: checking for curl-config
configure:5945: result: no
mmit was merged in 2.20.0:
>
> * The way -lcurl library gets linked has been simplified by taking
> advantage of the fact that we can just ask curl-config command how.
>
> Unfortunately it assumes that curl-config is in the path which is not
> always the case. When using "--wi
just ask curl-config command how.
Unfortunately it assumes that curl-config is in the path which is not always
the case. When using "--with-curl=/path/to/curl" in the configure command, the
path to the actual curl-config executable is ignored and the build fails around
here:
CC ht
From: Philip Oakley
Upon seeing the '-lcurl' option, point to the libcurl.lib.
While there, fix the elsif indentation.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
contrib/buildsystems/engine.pl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/con
We could probably fix this just by loosening missing_target(). However,
there's other code which looks at the curl result, and it would have to
be tweaked as well. Instead, let's just normalize the result the same
way the smart-http code does.
There's a similar case in processing
*result = CURLE_HTTP_RETURNED_ERROR;
/*
* Normally curl will already have put the "reason phrase"
* from the server into curl_errorstr; unfortunately without
* FAILONERROR it is lost, so
I'm trying to build Git and install it in a discardable directory. All
of Git's prereqs have been built and are there.
Git was configured with --with-curl, but it looks like Git cannot find
the cURL built for it (see below). I tried adding -lcurl to LDLIBS but
it does not appear to
Hi Junio,
On Wed, 6 Mar 2019, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Johannes Schindelin via GitGitGadget"
> > writes:
> >
> >> As suggested by Jeff King in a nearby thread.
> >>
> >> Johannes Schindelin (1)
Junio C Hamano writes:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
>> As suggested by Jeff King in a nearby thread.
>>
>> Johannes Schindelin (1):
>> remote-curl: mark all error messages for translation
>
> Does this come on top or b
"Johannes Schindelin via GitGitGadget"
writes:
> As suggested by Jeff King in a nearby thread.
>
> Johannes Schindelin (1):
> remote-curl: mark all error messages for translation
Does this come on top or below the anonymize patch, or it does not
matter which goes firs
, got
flush packet"));
strbuf_reset(&exp);
strbuf_addf(&exp, "# service=%s", service);
if (strcmp(line, exp.buf))
- die("invalid server response; got '%s'", line);
+
As suggested by Jeff King in a nearby thread.
Johannes Schindelin (1):
remote-curl: mark all error messages for translation
remote-curl.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
base-commit
Hi Peff,
On Tue, 5 Mar 2019, Jeff King wrote:
> On Mon, Mar 04, 2019 at 07:33:46AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > @@ -442,17 +443,23 @@ static struct discovery *discover_refs(const char
> > *service, int for_push)
> > break;
> > case HTTP_MISSING_TAR
On Mon, Mar 04, 2019 at 07:33:46AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> Just like 47abd85ba0 (fetch: Strip usernames from url's before storing
> them, 2009-04-17) and later 882d49ca5c (push: anonymize URL in status
> output, 2016-07-13), this change
I have just noticed locally that certain errors (in my case, a stale entry
in /etc/hosts) use the un-scrubbed URL in the error message when dying.
Let's scrub them.
Johannes Schindelin (1):
curl: anonymize URLs in error messages and warnings
remote-curl.c | 19 +--
1
From: Johannes Schindelin
Just like 47abd85ba0 (fetch: Strip usernames from url's before storing
them, 2009-04-17) and later 882d49ca5c (push: anonymize URL in status
output, 2016-07-13), this change anonymizes URLs (read: strips them of
user names and especially passwords) in user-facing error m
On Thu, Feb 21, 2019 at 12:24:41PM -0800, Jonathan Tan wrote:
> When transmitting and receiving POSTs for protocol v0 and v1,
> remote-curl uses post_rpc() (and associated functions), but when doing
> the same for protocol v2, it uses a separate set of functions
> (proxy_rpc(
On Fri, Feb 22, 2019 at 8:18 AM Eric Sunshine wrote:
> On Thu, Feb 21, 2019 at 3:25 PM Jonathan Tan wrote:
> > + for i in $(test_seq 1 1500)
> > + do
> > + # do not use here-doc, because it requires a process
> > + # per loop iteration
> > + e
On Thu, Feb 21, 2019 at 3:25 PM Jonathan Tan wrote:
> diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh
> @@ -542,7 +542,38 @@ test_expect_success 'clone with http:// using protocol
> v2' '
> +test_expect_success 'clone big repository with http:// using protocol v2' '
> + test_wh
The argv field in struct rpc_state is only used in rpc_service(), and
not in any functions it directly or indirectly calls. Refactor it to
become an argument of rpc_service() instead.
Signed-off-by: Jonathan Tan
---
remote-curl.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
When transmitting and receiving POSTs for protocol v0 and v1,
remote-curl uses post_rpc() (and associated functions), but when doing
the same for protocol v2, it uses a separate set of functions
(proxy_rpc() and others). Besides duplication of code, this has caused
at least one bug: the auth retry
Currently, whenever remote-curl reads pkt-lines from its response file
descriptor, only the payload is written to its buf, not the 4 characters
denoting the length. A future patch will require the ability to also
write those 4 characters, so in preparation for that, refactor this read
into its own
The stdin_preamble field in struct rpc_state is only used in
rpc_service(), and not in any functions it directly or indirectly calls.
Refactor it to become an argument of rpc_service() instead.
An observation of all callers of rpc_service() shows that the preamble
is always set, so we no longer ne
The result field in struct rpc_state is only used in rpc_service(), and
not in any functions it directly or indirectly calls. Refactor it to
become an argument of rpc_service() instead.
Signed-off-by: Jonathan Tan
---
remote-curl.c | 25 +
1 file changed, 13 insertions(+)
troduced in patch 4 of this set - I'll update that one to
LARGE_PACKET_DATA_MAX and this one to LARGE_PACKET_MAX.
> > + if (status == PACKET_READ_FLUSH)
> > + /*
> > +* We are done reading for this request, but we
> > +
* We are done reading for this request, but we
> + * still need to send this line out (if
> + * rpc->write_line_lengths is true) so do not
> + * return yet.
> +
Change one hard-coded use of the constant 40 to a reference to
the_hash_algo. In addition, switch a use of get_oid_hex to
parse_oid_hex to avoid the need to use a constant.
Signed-off-by: brian m. carlson
---
remote-curl.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff
Jonathan Tan writes:
> + # Ensure that the list of wants is greater than http.postbuffer below
> + for i in $(seq 1 1500)
test_seq.
> + do
> + test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/big" "commit$i"
> + done &&
> +
> + GIT_TRACE_PACKET="$(pwd)/log" GIT_TRACE_CU
Currently, whenever remote-curl reads pkt-lines from its response file
descriptor, only the payload is written to its buf, not the 4 characters
denoting the length. A future patch will require the ability to also
write those 4 characters, so in preparation for that, refactor this read
into its own
The argv field in struct rpc_state is only used in rpc_service(), and
not in any functions it directly or indirectly calls. Refactor it to
become an argument of rpc_service() instead.
Signed-off-by: Jonathan Tan
---
remote-curl.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
The result field in struct rpc_state is only used in rpc_service(), and
not in any functions it directly or indirectly calls. Refactor it to
become an argument of rpc_service() instead.
Signed-off-by: Jonathan Tan
---
remote-curl.c | 25 +
1 file changed, 13 insertions(+)
When transmitting and receiving POSTs for protocol v0 and v1,
remote-curl uses post_rpc() (and associated functions), but when doing
the same for protocol v2, it uses a separate set of functions
(proxy_rpc() and others). Besides duplication of code, this has caused
at least one bug: the auth retry
The stdin_preamble field in struct rpc_state is only used in
rpc_service(), and not in any functions it directly or indirectly calls.
Refactor it to become an argument of rpc_service() instead.
An observation of all callers of rpc_service() shows that the preamble
is always set, so we no longer ne
On Tue, Feb 12 2019, brian m. carlson wrote:
> Change one hard-coded use of the constant 40 to a reference to
> the_hash_algo. In addition, switch a use of get_oid_hex to
> parse_oid_hex to avoid the need to use a constant.
>
> Signed-off-by: brian m. carlson
> ---
> remote-curl.c | 11 ++
Change one hard-coded use of the constant 40 to a reference to
the_hash_algo. In addition, switch a use of get_oid_hex to
parse_oid_hex to avoid the need to use a constant.
Signed-off-by: brian m. carlson
---
remote-curl.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff
On Mon, Feb 11, 2019 at 11:20:54AM -0800, Jonathan Tan wrote:
> > In the case of proxy_request(), we don't know ahead of time whether the
> > request is large or not; we just proxy the data through. And we don't do
> > the probe thing at all. So wouldn't we dropping some data for the
> > follow-up
> On Tue, Feb 05, 2019 at 04:21:22PM -0800, Jonathan Tan wrote:
>
> > In post_rpc(), remote-curl calls credential_fill() if HTTP_REAUTH is
> > returned, but this is not true in proxy_request(). Do this in
> > proxy_request() too.
>
> Can we do this as a general r
Jeff King writes:
> Yep. Here it is.
>
> Rather than a range-diff, which is quite large due to the code movement,
> I'll include below the interesting hunk of a diff between the two
> endpoints (i.e., what we would have seen applying the packet-err-check
> changes on top of my code movement, whic
On Tue, Feb 05, 2019 at 04:21:22PM -0800, Jonathan Tan wrote:
> In post_rpc(), remote-curl calls credential_fill() if HTTP_REAUTH is
> returned, but this is not true in proxy_request(). Do this in
> proxy_request() too.
Can we do this as a general rule? If we look at the code in
On Wed, Feb 06, 2019 at 11:29:03AM -0800, Josh Steadmon wrote:
> > + packet_reader_init(&reader, -1, d->buf, d->len,
> > + PACKET_READ_CHOMP_NEWLINE |
> > + PACKET_READ_DIE_ON_ERR_PACKET);
> > + if (packet_reader_read(&reader) != PACKET_READ_NORMAL)
>
Josh Steadmon writes:
>> +packet_reader_init(&reader, -1, d->buf, d->len,
>> + PACKET_READ_CHOMP_NEWLINE |
>> + PACKET_READ_DIE_ON_ERR_PACKET);
>> +if (packet_reader_read(&reader) != PACKET_READ_NORMAL)
>> +die("invalid server respon
On 2019.02.06 14:18, 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. W
In a v2 smart-http conversation, the server should reply to our initial
request with a pkt-line saying "version 2". We check that with
starts_with(), but really that should be the only thing in that packet.
A response of "version 20" should not match.
Let's tighten this check to use strcmp(). Note
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 a
iff, which is quite large due to the code movement,
I'll include below the interesting hunk of a diff between the two
endpoints (i.e., what we would have seen applying the packet-err-check
changes on top of my code movement, which is more or less what I did to
generate it).
Josh's
In post_rpc(), remote-curl calls credential_fill() if HTTP_REAUTH is
returned, but this is not true in proxy_request(). Do this in
proxy_request() too.
When t5551 is run using GIT_TEST_PROTOCOL_VERSION=2, one of the tests
that used to fail now pass.
Signed-off-by: Jonathan Tan
---
remote
Jeff King writes:
> 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:
> ...
>
> - we now predicate the smart/dumb decision entirely on the presence of
>the correct content-typ
In post_rpc(), remote-curl calls credential_fill() if HTTP_REAUTH is
returned, but this is not true in proxy_request(). Do this in
proxy_request() too.
When t5551 is run using GIT_TEST_PROTOCOL_VERSION=2, one of the tests
that used to fail now pass.
Signed-off-by: Jonathan Tan
---
remote
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -545,14 +545,22 @@ static curlioerr rpc_ioctl(CURL *handle, int cmd, void
*clientp)
}
#endif
+struct rpc_in_data {
+ struct rpc_state *rpc;
+};
+
+/*
+ * A callback for CURLOPT_WRITEFUNCTION. The return value is the bytes consumed
+ * from ptr
By not setting CURLOPT_FAILONERROR, curl parses the HTTP response
headers even if the response is an error. This makes GIT_CURL_VERBOSE to
show the HTTP headers, which is useful for debugging.
Signed-off-by: Masaya Suzuki
---
remote-curl.c | 10 ++
1 file changed, 10 insertions(+)
diff
By not setting CURLOPT_FAILONERROR, curl parses the HTTP response
headers even if the response is an error. This makes GIT_CURL_VERBOSE to
show the HTTP headers, which is useful for debugging.
Signed-off-by: Masaya Suzuki
---
remote-curl.c | 10 ++
1 file changed, 10 insertions(+)
diff
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -545,14 +545,22 @@ static curlioerr rpc_ioctl(CURL *handle, int cmd, void
*clientp)
}
#endif
+struct rpc_in_data {
+ struct rpc_state *rpc;
+};
+
+/*
+ * A callback for CURLOPT_WRITEFUNCTION. The return value is the bytes consumed
+ * from ptr
From: Jeff King
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 l
From: Jeff King
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 e
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 wou
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. W
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
spec.
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
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 ti
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 a
claiming "text/html" (and after my patch, 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 comm
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
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
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.
> >
>
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).
>
>
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
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).
> >
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
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
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
>
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
>
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
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
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
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
1 - 100 of 577 matches
Mail list logo
