Re: [PATCH v4] remote-curl: fix large pushes with GSSAPI

[Jeff King <peff@peff.net>]

On Wed, Oct 30, 2013 at 10:40:30PM +0000, brian m. carlson wrote:

> If you would split it out, that would be great.  Then I'll simply rebase
> my patch on top of yours and go from there.

I just included your patch on top, since it was the residue left over
after committing my refactoring. Please read over the result to make
sure I am not defaming you. :)

I noticed while committing the first patch that we do not actually
follow the "do not look at curl after finish_active_slot" rule for the
content-type. Again, we get away with it because we are not running
multiple slots at the time (we only check content-type during the
initial discovery).

I think the refactoring here is the cleanest thing by the existing
rules, but I also think we could get away with the somewhat simpler
patch of just teaching probe_rpc to grab the AUTHAVAIL (because it still
has the old slot and does not need to call get_active_slot again, and
because we know we are only using a single slot).

Going through all of this, I can't help but be annoyed at how much http
baggage we are carrying around for the curl_multi code for parallel
fetches, which is only used for dumb http. The smart-http code would be
happy with a single curl handle we used each time. But I imagine there
are still people relying on dumb http, and dropping the parallel fetch
would be a pretty severe regression for them.

  [1/3]: http: return curl's AUTHAVAIL via slot_results
  [2/3]: remote-curl: pass curl slot_results back through run_slot
  [3/3]: remote-curl: fix large pushes with GSSAPI

-Peff