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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
