Jonathan Nieder wrote: > This series seems to be instead about ensuring that authentication > succeeds before proceding, within the same connection.
(I mean within handling of the same request, not the same connection.) Using "Expect: 100-Continue" would also be an alternative way to support large pushes that need to follow redirects if we didn't have peff's "http: update base URLs when we see redirects". Forgive my ignorance: is there a way to do something analagous to that patch but for GSS-Negotiate authentication? In other words, after using the first request to figure out what authentication mechanism the server prefers, could git prefer it in remaining requests to avoid the need to rewind? I don't see any simple way to do that using the libcurl API. If checking if the server accepts GSS-Negotiate authentication and using that to decide whether to 'Expect: 100-Continue' is easier, that would be fine, too. If neither is straightforward to do, the configuration seems like a fine workaround --- the documentation would just have to explain that this option is meant to be set on a per-host basis in '[http "<url>"]' sections, to true for hosts you intend to use with GSS-Negotiate auth and false for hosts with broken 100-continue support. Thanks, Jonathan -- 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
