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

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

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