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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html