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.
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