Re: [whatwg/fetch] CORS safelisting trace context header (#911)

I can’t find anywhere in the issue description that provides an explanation of any problem specific/unique to exchanging distributed trace contexts that’s caused by the CORS preflight.

As far as the problems that are cited (in *“this poses two challenges for observability providers”*):

> The preflight request increases the latency for the original HTTP request since there is an extra roundtrip to verify that the application can access the HTTP resource

That’s a general problem/cost with any situation at all where a preflight happens. It’s not on its own sufficient justification at all for special-casing the `traceparent` and `tracestate` request headers.

> Unless the server (managed by observability user) is modified to respond appropriately to the preflight request, the request would fail. This prevents observability providers from propagating the trace context across cross-origin requests by default, therefore relying on the user to modify each of their services.

That’s also a general requirement with any situation at all where a preflight can happen. It’s also not on its own sufficient justification at all for special-casing  `traceparent` and `tracestate`.

The server managed by observability user must anyway at least be modified to send the Access-Control-Allow-Origin response header back, right? Otherwise, no frontend JavaScript code will be able to access responses from that server anyway — even for simple requests that require no preflight.

Given that, in what way is it significantly more difficult for an observability user to modify their server-side system with complete CORS support, including handling for the preflight OPTIONS request?

And doesn’t an observability user already need to modify their server-side system in some way to participate in exchanging (consuming?) of distributed trace contexts to begin with?

If so, why wouldn’t it be expected that when making the necessary modifications to participate in exchanging (consuming?) of distributed trace contexts to begin with, the observability user would at that time also fully CORS-enable their server-side system — including handling for preflights?

What is special/unique about the observability-user case that makes it specifically more challenging for observability users to add CORS-preflight support to their systems than it is for anyone else managing a server-side system intended to receive cross-origin requests from frontend code?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/911#issuecomment-504063973