Client: Optimize default retry strategy

[welkeyever]

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

• make sure all the retry cases in client is reasonable
• decide whether to enable the retry policy by default(add an option to control?)

Describe alternatives you've considered

compatibility needs to be considered (the influence to the existing user)

Additional context

https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2

[CSWYF3634076]

I want to try this.

[Duslia]

Well done!

[CSWYF3634076]

Thank you for your trust. I will sort out the plan as soon as possible

[Duslia]

Hertz client has default retry logic with low threshold. And user doesn't know this normally. So I turn off the default retry logic and user needs to open it manually.

[CSWYF3634076]

What does retry "cases” mean? In other words, which part of the code should I focus on. I read "pkg/protocol/http1/client go::Do()" . I don't know if the direction is right

[welkeyever]

Yes, and and all scenarios where doNonNilReqResp(https://github.com/cloudwego/hertz/blob/develop/pkg/protocol/http1/client.go#L522) returns true/false.

However, the default logic is changed by #102 , so here we only need to care about the retry scenarios.

1. Sort out all possible retry scenarios.
2. Comb through the configurable options currently available to users.
3. Determine whether the retries currently provided by the framework are reasonable
4. Are there any retry scenarios that cannot be covered currently?
5. etc...

[Duslia]

Hi~ I am wondering how it's going? Do you encounter any difficulties? You may join our Feishu Chat Group to discuss more details about this task.