100-continue support in transport layer

[Jinming-Hu]

Is your feature request related to a problem? Please describe. There's an issue in FE some time back that casued FE machines to go down. It was due to high traffic generated by storage clients, even when the storage account was throttled.

Describe the solution you'd like There's an ongoing discussion to come up with a unified solution across all clients/sdks. Basically storage client sdk needs to leverage Expect: 100-continue request header to prevent unnecessary payload transfer when service throttles client's traffic.

Transport layer needs to provide an option to storage, so that storage can decide whether to add Expect: 100-continue request header on pre-request basis in retry policy.

100-continue is already implemented and by-default enabled for PUT requests in libcurl transport layer. The only things we need to do is to expose an option to storage, and also to enable it for PATCH and POST requests.

100-continue is not implemented in WinHTTP transport layer.

Describe alternatives you've considered None

Additional context I assume you're already involved in the discussion. See more details in email threads.

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [x] Description Added
• [x] Expected solution specified

[vhvb1989]

We don't have a common abstraction for HttpTransportOptions. So, for adding the use 100-continue option, our options are:

• Independent option for each transport adapter options.
• An option for the Pipeline Transport Policy.

Other questions for @Jinming-Hu

• Do we need to support this feature per-operation? or only per-sdk-client?
• Do we need to ever do PUT (upload) without using 100-continue ? , in other words: Do you expect the client to decide whether or no to use 100-continue for PUT/PATCH/POST? or only for PATCH/POST? (leaving PUT as an always use 100-continue)

[Jinming-Hu]

I'd prefer independent option for each transport adapter options.

Other questions: according to the design, both answers are yes.

Anyway, I'm not in the discussion and I don't know all the details. Maybe you can contact the feature owner to get the latest update?

[vhvb1989]

I'd prefer independent option for each transport adapter options.

Other questions: according to the design, both answers are yes.

Anyway, I'm not in the discussion and I don't know all the details. Maybe you can contact the feature owner to get the latest update?

I'm confused. Didn't you create the issue?

[Jinming-Hu]

Hi @vhvb1989 , this is a cross-language feature. We need to have the same implementation across all storage clients. There's a design, but as far as I know the details are still under discussion. There's nothing we need to do at the moment until we have a conclusion. I've done some preliminary study, in this issue is what I expect we'll need if the design becomes final.

[github-actions[bot]]

Hi @Jinming-Hu, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.