[feature] add a new http pipeline policy for special header `client-request-id` and `return-client-request-id`

Batch service will have special header client-request-id and return-client-request-id set in HTTP request for diagnostic instead of x-ms-client-request-id and x-ms-return-client-request-id which are used in other Azure Service for diagnostic.

Current in .Net Azure.Core pipeline, the ClientRequestIdPolicy is added into pipeline by default, so each http request has x-ms-client-request-id and x-ms-return-client-request-id see following: https://github.com/Azure/azure-sdk-for-net/blob/592196f5c96a5bfdb7ab29fd28fec2db6edffdcd/sdk/core/Azure.Core/src/Pipeline/HttpPipelineBuilder.cs#L148-L149

policies.Add(ClientRequestIdPolicy.Shared); 

Expected behavior: in each http request message, there are client-request-id and return-client-request-id but there are no x-ms-client-request-id and x-ms-return-client-request-id.

So there are two possible approach:

approach 1

update existing ClientRequestIdPolicy and let it accept a parameter to customize the head name, and in HttpPipelineBuilder will update the head name when add it.

approach 2

To recognize those two headers,

• SDK will instrument a policy similar as ClientRequestIdPolicy into HTTP pipeline, and pipeline will append those two headers for each http request.

• And HttpPipelineBuilder will not add ClientRequestIdPolicy by default.

Current Azure.Core does not have such policy. Can we add this new policy in Azure.Core and export it either mark it public or define it in Azure.Core.Shared?

expected new policy:

namespace Azure.Core.Pipeline
{
    internal class AzureClientRequestIdPolicy : HttpPipelineSynchronousPolicy
    {
        internal const string ClientRequestIdHeader = "client-request-id";
        internal const string EchoClientRequestId = "return-client-request-id";

        protected AzureClientRequestIdPolicy()
        {
        }

        public static AzureClientRequestIdPolicy Shared { get; } = new AzureClientRequestIdPolicy();

        public override void OnSendingRequest(HttpMessage message)
        {
            message.Request.Headers.SetValue(ClientRequestIdHeader, message.Request.ClientRequestId);
            message.Request.Headers.SetValue(EchoClientRequestId, "true");
        }
    }
}

[m-nash]

@jsquire as discussed in our last core sync, @chunyu3 will do an estimation exercise on what it would take to update the generator / custom code to no longer use the policy but instead simply add the headers always at request creation time.

@christothes was going to do an estimation exercise on how many fully hand written libraries would be impacted.

After both of these we were going to decide if we wanted to go with replacing the policy or not.

If we decide to replace the policy we need to be able to roll this out in a 2 phase process where adding the headers at the request level doesn’t conflict in a negative way with the policy. This could be a simple change in the policy to check existence before adding or some other mechanism. We would add the generator / manual code then once we are confident in the changes remove the policy from being added in the default pipeline.

If we decide not to replace the policy we need some public mechanism to change the name of the header to use since this is hard coded today.

In the meantime to unblock batch we will create an internal policy that runs after the Azure.Core one, removes the default named headers and adds the custom named headers.

[jsquire]

@chunyu3 : Can you please help us understand why this should be in Core rather than specific to Batch? Is this something that we believe is a pattern that we’ll see across Azure services? Do we have other examples of it in use currently?