Open codefromthecrypt opened 6 years ago
@nonspecialist mind having a crack at fixing this?
@adriancole C# is really not my strong point (I only picked it up 2 days ago) but I'll have a crack at it
@adriancole I'm looking for clarification on the B3 Propagation spec, and what should happen if X-B3-Flags
is received with a value of 0
. According to the spec:
Flags value | Sampled value | is valid? | meaning |
---|---|---|---|
1 | 0 | no | debugging implies accept, Sampled should not be passed |
1 | 1 | no | as above |
1 | unset | yes | as above |
unset | 0 | yes | do not sample |
unset | 1 | yes | force sampling |
unset | unset | yes | receiver to determine whether to sample |
0 | 0 | unspecified | presumably, do not sample? |
0 | 1 | unspecified | presumably, force sampling? |
0 | unset | unspecified | presumably, receiver to determine? |
What's unclear is whether a sender should ever emit X-B3-Flags: 0
at all and if it does, is there an implication to turn off debugging even if the receiver has it turned on?
I wouldn't interpret Flags 0 in any way except for the same as unset
Hinting from the below comment and an encoding bug I think flags needs to be revisited:
The
X-B3-Flags
header back maybe 2012 or so was thinking about becoming more, but never did. Reasons including awkward overlap with sampled, and also it is mainly covering binary encoding concerns, not http ones. For this reason, back in the day, we documentedX-B3-Flags
based on how all the libraries worked, essentially 1 being the only valid value, which is the debug flag.https://github.com/openzipkin/b3-propagation#debug-flag-1
Emitting bitset behavior will actually either restart traces or reset the sampling decision, so this should be changed fairly urgently to only send the header when debug is set and not otherwise.
See openzipkin/zipkin-go#53