Some large projects (Android, Chrome), use git with a distributed backend to feed changes to automated builders and such. We can actually get into a case where DDOS mitigation kicks in and 429s start going out. In that case I think it's pretty important that we honor the Retry-After field so we're good citizens and whoever's running the backend service has some options for traffic shaping to manage load. In general you're right it doesn't matter _that_ much but in at least the specific case I have in my head, it does. On Wed, Oct 14, 2020 at 1:34 PM Jeff King <peff@xxxxxxxx> wrote: > > On Wed, Oct 14, 2020 at 01:10:46PM -0600, Sean McAllister wrote: > > > On Wed, Oct 14, 2020 at 1:09 PM Sean McAllister <smcallis@xxxxxxxxxx> wrote: > > > > > > On Tue, Oct 13, 2020 at 3:14 PM Jeff King <peff@xxxxxxxx> wrote: > > > > > > > > I do think you could be leveraging CURLINFO_RETRY_AFTER rather than > > > > implementing your own header parsing, though. > > > > > > > Ah I didn't know about CURLINFO_RETRY_AFTER, I'll look at that and use > > > it if I can. > > > > > I took a look, it looks like CURLINFO_RETRY_AFTER was only added in > > 7.66 (September, 2019), so > > I don't think it's reasonable to rely on it for getting the > > Retry-After value in this case. > > I agree that's pretty recent. > > How important is it that we respect it? I.e., we'd have some sane retry > behavior if the header is missing anyway. On older curl versions, how > bad would it be to just use that fallback behavior all the time? > > -Peff
