From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH 1/2] http: add option to enable 100 Continue responses
Date: Wed, 9 Oct 2013 15:30:54 -0400 [thread overview]
Message-ID: <20131009193054.GA3767@sigill.intra.peff.net> (raw)
In-Reply-To: <1381265287-39331-2-git-send-email-sandals@crustytoothpaste.net>
On Tue, Oct 08, 2013 at 08:48:06PM +0000, brian m. carlson wrote:
> When using GSS-Negotiate authentication with libcurl, the authentication
> provided will change every time, and so the probe that git uses to determine if
> authentication is needed is not sufficient to guarantee that data can be sent.
> If the data fits entirely in http.postBuffer bytes, the data can be rewound and
> resent if authentication fails; otherwise, a 100 Continue must be requested in
> this case.
>
> By default, curl will send an Expect: 100-continue if a certain amount of data
> is to be uploaded, but when using chunked data this is never triggered. Add an
> option http.continue, which defaults to enabled, to control whether this header
> is sent. The addition of an option is necessary because some proxies break
> badly if sent this header.
[+cc spearce]
I'd be more comfortable defaulting this to "on" if I understood more
about the original problem that led to 959dfcf and 206b099. It sounds
like enabling this all the time will cause annoying stalls in the
protocol, unless the number of non-crappy proxy implementations has
gotten smaller over the past few years.
> diff --git a/remote-curl.c b/remote-curl.c
> index b5ebe01..3b5e160 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -470,7 +470,12 @@ static int post_rpc(struct rpc_state *rpc)
>
> headers = curl_slist_append(headers, rpc->hdr_content_type);
> headers = curl_slist_append(headers, rpc->hdr_accept);
> - headers = curl_slist_append(headers, "Expect:");
> +
> + /* Force it either on or off, since curl will try to decide based on how
> + * much data is to be uploaded and we want consistency.
> + */
> + headers = curl_slist_append(headers, http_use_100_continue ?
> + "Expect: 100-continue" : "Expect:");
Is there any point in sending the Expect: header in cases where curl
would not send it, though? It seems like we should assume curl does the
right thing most of the time, and have our option only be to override
curl in the negative direction.
-Peff
next prev parent reply other threads:[~2013-10-09 19:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 20:48 [PATCH 0/2] HTTP GSS-Negotiate improvements brian m. carlson
2013-10-08 20:48 ` [PATCH 1/2] http: add option to enable 100 Continue responses brian m. carlson
2013-10-09 19:30 ` Jeff King [this message]
2013-10-09 21:19 ` Shawn Pearce
2013-10-09 21:37 ` Jeff King
2013-10-10 1:35 ` brian m. carlson
2013-10-10 1:43 ` Jeff King
2013-10-10 8:14 ` Shawn Pearce
2013-10-11 22:31 ` brian m. carlson
2013-10-12 2:02 ` Shawn Pearce
2013-10-08 20:48 ` [PATCH 2/2] Update documentation for http.continue option brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131009193054.GA3767@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).