Powershell: WebCmdlets should support retry

[TravisEz13]

suggested design
Invoke-WebRequest ... -RetryCount <int> -RetryIntervalSec <int>

[markekraus]

This one was on my personal wish list!

[ffeldhaus]

As there is already a pull request #5760 for this issue, I'd like to add my thoughts with regards to this new feature.

Many Web Services recommend that clients should implement a retry strategy to cope with intermittent failures of a web service, but also not to overload the service with too many subsequent requests (e.g. use Exponential Backof). But there are also other use cases for retries, where a client wants to regularly check if a Website comes online (retry until Status Code not 404), if a resource was modified (retry until Status Code not 304). Some responses may indicate, that the request rate should be reduced (e.g. AWS uses Status Code 503 "Slow Down"), which should be considered by a retry strategy.

In my opinion, PowerShell should allow to configure different strategies for retries. The following are some of my thoughts and points taken from the discussion in PR #5760:

• Parameter -Retry could indicate that the WebCmdlet should retry the request with a default, conservative, retry strategy
• Parameter -RetryCount could indicate how many retries should be made
• Parameter -RetryIntervalSec could indicate the interval between different request
• Parameter -RetryBackofStrategy could indicate if linear or exponential backof strategy should be used
• Parameter -RetryStatusCodes could contain a list of Status Codes for which the request is retried
• Parameters could also be set on WebSession in PrepareSession() and then have this area of code retrieve the values from WebSession. It would mean extending WebRequestSession to include new Properties

In my opinion this is such an important feature, that it requires more discussion and an agreement on how it should be implemented, before work is continued on the PR.

[markekraus]

I agree that we should consider the design more thoroughly before work continues in the PR. At present, users can roll their own retry and backoff strategies, so it is not urgent that we include this feature. However, including the wrong feature may make us a bad citizen and promote poor behavior. I definitely don't want that.

/cc @adityapatwardhan @SteveL-MSFT

[SteveL-MSFT]

I'll just add a couple of thoughts:

1. it seems that there's enough discussion to warrant a RFC
2. by default, we should borrow from curl making the assumption they've already spent time going through design discussion unless there's something that we can improve upon
3. there doesn't need to be a single PR to address all the requests, we can do them in stages as long as subsequent PRs build upon previous PRs and don't introduce confusion or compatibility breaks