Response contains invalid Sampled header value

[marcingrzejszczak]

No description provided.

[codefromthecrypt]

we could qualify this further, I think. It seems to be copying all B3 request headers to the response, which is unnecessary overhead. By not doing that, we automatically fix the one with the wrong sample state.

[marcingrzejszczak]

Hmm but isn't it nice to send a request and in the response get the info about the trace id (at least). Or actually from the user's perspective getting the trace id is the only thing that could matter. We could limit the headers to contain only the trace id actually.

[codefromthecrypt]

My opinion is to not copy any of the propagation headers to the response automatically. Trace ids aren't the same as end-user "request ids", which are often copied to the response. Once we escalate something into user namespace we have other problems. What do we say when people have user support asking what this id is about? What if someone finds that leaking the trace ids makes some attack easier? What if we want to use a different header for propagation in the future? We don't have any of these problems if we simply don't do this.

[marcingrzejszczak]

Fair enough - let's remove them

[codefromthecrypt]

👍

PS it is relatively common for folks to ask to have tracing system re-use some externally managed "request ids" as "trace ids". That's one reason why zipkin doesn't require the trace id to be a span id.

[devasat]

Please see #331

With the fix, header X-B3-TraceId wouldn't be in the response? I was using the trace id to find the trace in Zipkin. If this header is removed, how would I go about finding trace for a paritcular request in Zipkin?

curl -v http://localhost:8080
* Adding handle: conn: 0x7fc210803000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fc210803000) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 200 OK
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< X-B3-Sampled: 1
< X-B3-SpanId: c4adf4696a1334
< X-B3-TraceId: c4adf4696a1334
< X-Application-Context: frontend
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 28
< Date: Sat, 09 Jul 2016 13:04:41 GMT
<
* Connection #0 to host localhost left intact
Sat Jul 09 09:04:41 EDT 2016

[marcingrzejszczak]

You can search for it in the logs and in Zipkin. You know the time, you have tags etc. None of the existing tracing instrumentations is publishing this information in the response. Additionally, it can be problematic from the security perspective

[codefromthecrypt]

the typical ways would be to add a tag for your "request id" if there is one, basically the user-level request id. Then, you can search by that. If doing debugging, you can also start a trace from the client. In that case, you already know the trace id. ex. https://github.com/openzipkin/zipkin-browser-extension