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

From: Jeff King <peff@peff.net>
Date: Oct 10, 2013, 01:43 UTC
Message-ID: <20131010014319.GA15106@sigill.intra.peff.net>
In-Reply-To: <20131010013547.GA62549@vauxhall.crustytoothpaste.net>

On Thu, Oct 10, 2013 at 01:35:47AM +0000, brian m. carlson wrote:

Show 7 quoted lines

> > I don't have a GSS-enabled server to test on. Brian, can you try the
> > patch at the end of this message on your non-working server and see what
> > it outputs?
> 
> It doesn't trigger.  My server only requires authentication for the
> actual push operation, and it looks like your code doesn't trigger in
> that case.

Can you describe the sequence of requests, then?

Do you not have to auth for the info/refs request, and then have to auth later for the git-receive-pack request? Does the auth trigger for the probe_rpc call?

Can you show us GIT_CURL_VERBOSE=1 output for a session that fails (do note that it will dump your auth headers, so you may want to redact them before sharing)?

Show 7 quoted lines

> > > > 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.
> 
> I think curl expects that data in the POSTFIELDS option in order to
> trigger.  I wasn't able to get it to trigger on its own.

Was your POST perhaps not big enough? My impression is that it only sends it if the POST is too large to rewind (which seems like a good thing in general), and I thought earlier in the thread that command-line curl was sending one. I'm not sure what would be different for us here, once our manual "Expect" suppression is turned off.

-Peff