You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 5, 2020. It is now read-only.
The headers conflict with Azure Storage request signing process (#640). As a result Storage responds with 403 to all requests and issue is extremely hard to debug.
We have a special configuration to disable injection of the headers into requests to storage endpoints, however, we cannot guarantee that proper config is always applied.
Removing support for these headers would eliminate the issue without any configuration and save users a lot of pain with debugging it.
Before starting the implementation we need to:
[x] - clarify if headers are used by JS SDK: No
[x] - if JS SDK still emits x-ms headers, perhaps we can still remove them on injection side.
The text was updated successfully, but these errors were encountered:
Discussed with @iusafaro:
JavaScript SDK uses Request-Id header and does not use x-ms-request-id (and root) headers any longer. Customers pick up Javascript SDK dynamically whenever a new version is released.
Sorry for making this change that breaks your correlation.
There are 2 options for migration:
Keep x-ms headers on the client side:
set OperationCorrelationTelemetryInitializer.ParentOperationIdHeaderName to x-ms-request-id
set OperationCorrelationTelemetryInitializer.RootOperationIdHeaderName to x-ms-request-root-id
Change headers names on the client side, instead of sending x-ms- headers, send Request-Id header with value like |<something globally unique like a guid or 16 bytes random>
The headers were used for correlation and were deprecated with
(all of them released ~ a year ago)
The headers conflict with Azure Storage request signing process (#640). As a result Storage responds with 403 to all requests and issue is extremely hard to debug.
We have a special configuration to disable injection of the headers into requests to storage endpoints, however, we cannot guarantee that proper config is always applied.
Removing support for these headers would eliminate the issue without any configuration and save users a lot of pain with debugging it.
Before starting the implementation we need to:
[x] - clarify if headers are used by JS SDK: No
[x] - if JS SDK still emits x-ms headers, perhaps we can still remove them on injection side.
The text was updated successfully, but these errors were encountered: