On Fri, Oct 25, 2013 at 03:17:06AM -0400, Jeff King wrote:
> I think that makes sense. Would you also want to suppress the probe
> request in that case? It serves the same purpose, but would cause you to
> do an extra auth for no reason (which potentially means user input,
> which is annoying).
I
On Wed, Oct 23, 2013 at 10:56:32PM +, brian m. carlson wrote:
> On Tue, Oct 22, 2013 at 08:21:48PM -0700, Shawn Pearce wrote:
> > From my perspective, it is OK to defaulting to use 100-continue if the
> > server supports Negotiate. If the user is stuck behind a broken proxy
> > and can't authe
On Tue, Oct 22, 2013 at 08:21:48PM -0700, Shawn Pearce wrote:
> From my perspective, it is OK to defaulting to use 100-continue if the
> server supports Negotiate. If the user is stuck behind a broken proxy
> and can't authenticate, they can't authenticate. They can either set
> the variable to fal
On Wed, Oct 23, 2013 at 08:47:57AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Wouldn't a natural fix be to *always* use "Expect: 100-continue" when
> > and only when the probe_rpc() revealed a server supporting
> > GSS-Negotiate authentication?
>
> A stupid question. Is GSS-Neg
Jonathan Nieder writes:
> Wouldn't a natural fix be to *always* use "Expect: 100-continue" when
> and only when the probe_rpc() revealed a server supporting
> GSS-Negotiate authentication?
A stupid question. Is GSS-Negotiate the only special case?
--
To unsubscribe from this list: send the line
On Tue, Oct 22, 2013 at 8:00 PM, brian m. carlson
wrote:
> On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote:
>> 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
On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote:
> 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,
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 lar
Junio C Hamano wrote:
> +http.continue::
> + Ensure that authentication succeeds before sending the pack data when
> + POSTing data using the smart HTTP transport.
I think we always do that (since v1.7.5-rc0~82^2~1, "smart-http: Don't
use Expect: 100-Continue", 2011-02-15), in probe_r
"brian m. carlson" writes:
> On Sat, Oct 12, 2013 at 12:26:39AM +, brian m. carlson wrote:
>> On Fri, Oct 11, 2013 at 04:50:52PM -0700, Jonathan Nieder wrote:
>> > Perhaps this should be conditional on the authentication method used,
>> > so affected people could still contact broken servers
On Sat, Oct 12, 2013 at 12:26:39AM +, brian m. carlson wrote:
> On Fri, Oct 11, 2013 at 04:50:52PM -0700, Jonathan Nieder wrote:
> > Perhaps this should be conditional on the authentication method used,
> > so affected people could still contact broken servers without having
> > different confi
On Fri, Oct 11, 2013 at 04:50:52PM -0700, Jonathan Nieder wrote:
> brian m. carlson wrote:
> > +http.continue::
> > + Ensure that authentication succeeds before sending the pack data when
> > + POSTing data using the smart HTTP transport. This is done by
> > + requesting a 100 Continue respo
brian m. carlson wrote:
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1516,6 +1516,15 @@ http.postBuffer::
> massive pack file locally. Default is 1 MiB, which is
> sufficient for most requests.
>
> +http.continue::
> + Ensure that authentication succee
Explain the reason for and behavior of the new http.continue option, and that it
is disabled by default. Furthermore, explain that it is required for large
GSS-Negotiate requests but incompatible with some proxies.
Signed-off-by: brian m. carlson
---
Documentation/config.txt | 9 +
1 fi
14 matches
Mail list logo