git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/2] http: add option to enable 100 Continue responses

From
Jeff King <peff@peff.net>
Date
Oct 9, 2013, 19:30 UTC
Message-ID
<20131009193054.GA3767@sigill.intra.peff.net>
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:
Show 12 quoted lines
> 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.

Show 15 quoted lines
> 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
Previous: brian m. carlsonNext: Shawn Pearce
Message 3 of 11 in “HTTP GSS-Negotiate improvements”
  1. 0/2 HTTP GSS-Negotiate improvementsbrian m. carlson, Oct 8, 2013
  2. 1/2 http: add option to enable 100 Continue responsesbrian m. carlson, Oct 8, 2013
  3. Jeff KingOct 9, 2013
  4. Shawn PearceOct 9, 2013
  5. Jeff KingOct 9, 2013
  6. brian m. carlsonOct 10, 2013
  7. Jeff KingOct 10, 2013
  8. Shawn PearceOct 10, 2013
  9. brian m. carlsonOct 11, 2013
  10. Shawn PearceOct 12, 2013
  11. 2/2 Update documentation for http.continue optionbrian m. carlson, Oct 8, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.