API Management, Application Insights and "legacy" correlation protocol documentation

Question

When one enables Application Insights integration within Azure API Management, the legacy correlation protocol is selected by default. Where is this behaviour, along with the appropriate headers documented?

There is a link to the "Telemetry correlation within Application Insights", but it is unclear which of these describe the legacy protocol in the context of API Management.

Concrete questions:

• I assume the protocol choice within APIM affects which headers (request correlation identifiers) are a) added to the the incoming request metadata when it is logged into AI by APIM, as well as b) which headers are passed along to the backend API. Is this understanding correct?
• In case the client provides the headers in the original request, are those automatically handled and passed along appropriately? If so, what should the headers be - depending on the protocol selection?
• An example APIM policy for adding a correlation ID is provided here. Does this behaviour still need to be explicitly defined within a policy? The example uses the header 'correlationid'. I've also seen 'correlation-id' and 'x-correlation-id' forms having been used e.g. here - further adding into the confusion. Neither of those headers are mentioned in the "Telemetry correlation within AI" document. So again, what are the headers we should be using exactly?

Answer 1

For the benefit of anyone else looking at this question which is quite old

(Apologies to the original author that it did not get answered)

App Insights should now default to using the W3C distributed trace specification (as explained here)

That means that when you enable App Insights against an API in API Management one of two things will happen and either way
(a) A request telemetry is written representing the client request
(b) A dependency telemetry representing the forwarded request to the configured backend

One: If the client request already contains a trace header the trace-Id is used (in App Insights terms this is "operation id"). This is propagated to the backend with a new span
or Two: if the client request does NOT already contain a trace header then a new operation id is assigned and the outgoing request has a new trace header added with the new operation id (or trace-id in w3c terms).