Re: [PATCH v2 2/2] Update documentation for http.continue option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 response.  For requests larger than
> > +	'http.postBuffer', this is required when using GSS-Negotiate
> > +	(Kerberos) authentication over HTTP.  However, some proxies do not
> > +	handle the protocol exchange gracefully; for them, this option must be
> > +	disabled.  Defaults to disabled.
> 
> It's not only your company's proxy that might mishandle 100-continue
> but the target server's reverse proxy (or from the point of view of
> the user, the target server), right?
> 
> I think the wording could be clearer about the impact of the setting
> ("some proxies and reverse proxies" or something).

I'm unclear about what systems are actually broken, since I don't deal
with any such systems.  One of Shawn Pearce's commit messages definitely
covered broken proxies, but it could really be anything beyond the
client: proxies, reverse proxies, servers, or even rogue intermediaries
(for non-TLS connections).

> Perhaps this should be conditional on the authentication method used,
> so affected people could still contact broken servers without having
> different configuration per server and without having to wait a second
> for the timeout.

curl determines what method, but I guess it's safe to assume that the
authentication method used for the probe will be the same as the one
used for the final connection.  Unfortunately, all curl will tell us is
what was offered, not what it would have chosen, so if GSSAPI and
something non-Basic are both offered, we'd have to make a guess.  (curl
will always prefer non-Basic to Basic for the obvious reasons.)

If you can argue for some sane semantics in what we should do in that
case, I'll reroll with that fix and a clearer wording for the docs.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]