search

w3c / baggage

Propagation format for distributed context: Baggage
https://w3c.github.io/baggage/
Other
46 stars 18 forks source link

Clarification on how baggage should be propagated when using websockets #115

Closed mediocregopher closed 1 year ago

mediocregopher commented 1 year ago

The baggage standard does not explicitly state that browser are expected to be able to send the baggage HTTP header, but this is implied by the other risks section with the mention of single page apps and access control headers. So I'm assuming that it is intended for browsers to be able to send baggage data to backend services.

In that context, is there any guidance on how browsers can do this when opening a websocket connection? There is no mechanism for a browser to set an HTTP header when creating a websocket connection. The only alternative I can think of is to specify a way of setting the value on the URL query (e.g. /endpoint?baggage=<URL encoded baggage value>), but I'm hoping others might have a more elegant solution.

basti1302 commented 1 year ago

The specification currently targets HTTP exclusively. The assumption that the spec "is intended for browsers" is not entirely correct, it is intended for communication parties that communicate via HTTP. Browser might be such a communication party, but the spec does not claim or even strive to cover every aspect of what browsers can do.

As you can see in the section about the format, this is only specified in terms of an HTTP header. Ultimately, other protocols might or might not be included in the specification in future versions. By the way, the same question/discussion exists for the W3C trace context specification (see https://www.w3.org/TR/2022/WD-trace-context-2-20220929/#other-communication-protocols).

In practical terms, extending the specification to other protocols always relies on whether some kind of meta data (like headers) is available for the communication channel.

As an aside: With respect to websockets, I wonder which use case there is for including baggage when opening the connection. The more likely use case (at least in my opinion) is to include baggage with each individual websocket request. As far as I can see, the specification cannot really help with that, since websocket frames have no meta data. Baggage data would need to be included in the payload, which is always application specific.

If you indeed want to including baggage when opening the connection, including it as a query parameter seems to be a safe bet. On the server side you can translate this into baggage that can be propagated further downstream as described by this spec. But IMO this is something that applications need to handle on their own as it is outside of the scope of this specification.

mediocregopher commented 1 year ago

Thank you for the clarification, we'll move forward with passing the baggage as a query parameter.