http - RetryHandler MUST respect retry-after: <date>

[baywet]

more details microsoft/kiota#596

[voidstackloop]

I’d like to work on this. The current HTTP component has no retry middleware, so I’ll keep the contribution focused: wire Faraday’s maintained retry middleware into the default pipeline with Kiota’s standard retry statuses/limits, and add regression coverage proving an HTTP-date Retry-After value is converted to the correct delay.

[baywet]

Please go ahead, however, we made an explicit design decision to implement our own middleware and not to rely on the default clients implementations to provide a consistent experience across languages.

Here is the dotnet implementation for reference.

https://github.com/microsoft/kiota-dotnet/blob/main/src/http/httpClient/Middleware/RetryHandler.cs

[voidstackloop]

Thanks for the clarification. I updated #150 to use a Kiota-owned Faraday middleware based on the .NET behavior and removed the faraday-retry dependency. It now handles 429/503/504 responses, delay-seconds and HTTP-date Retry-After values, bounded retries/delays, the Retry-Attempt header, and avoids replaying non-rewindable bodies.

The HTTP component suite passes (16 examples), and RuboCop reports no offenses on the revised files. Please take another look when convenient.