From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Shawn Pearce" <spearce@spearce.org>, git <git@vger.kernel.org>,
"Junio C Hamano" <gitster@pobox.com>,
"Nguyễn Thái Ngọc" <pclouds@gmail.com>
Subject: Re: [PATCH 1/2] http: add option to enable 100 Continue responses
Date: Wed, 9 Oct 2013 21:43:19 -0400 [thread overview]
Message-ID: <20131010014319.GA15106@sigill.intra.peff.net> (raw)
In-Reply-To: <20131010013547.GA62549@vauxhall.crustytoothpaste.net>
On Thu, Oct 10, 2013 at 01:35:47AM +0000, brian m. carlson wrote:
> > 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)?
> > > > 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
next prev parent reply other threads:[~2013-10-10 1:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 20:48 [PATCH 0/2] HTTP GSS-Negotiate improvements brian m. carlson
2013-10-08 20:48 ` [PATCH 1/2] http: add option to enable 100 Continue responses brian m. carlson
2013-10-09 19:30 ` Jeff King
2013-10-09 21:19 ` Shawn Pearce
2013-10-09 21:37 ` Jeff King
2013-10-10 1:35 ` brian m. carlson
2013-10-10 1:43 ` Jeff King [this message]
2013-10-10 8:14 ` Shawn Pearce
2013-10-11 22:31 ` brian m. carlson
2013-10-12 2:02 ` Shawn Pearce
2013-10-08 20:48 ` [PATCH 2/2] Update documentation for http.continue option brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131010014319.GA15106@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).