Change span injection/extraction from HTTP request#821
Merged
basvanbeek merged 1 commit intogo-kit:masterfrom Jan 9, 2019
nboukeffa:jaeger-span-default-format
Merged
Change span injection/extraction from HTTP request#821basvanbeek merged 1 commit intogo-kit:masterfrom nboukeffa:jaeger-span-default-format
basvanbeek merged 1 commit intogo-kit:masterfrom
nboukeffa:jaeger-span-default-format
Conversation
Today, `TextMap` format is used when injecting or extracing *span* from HTTP requests. This format will treat the HTTP header value (that contains the span) as is (without decoding). Conversely the `HTTPHeaders` format will try to URL decode the value first. The issue is that some opentracing clients like [java jaeger client](https://github.com/jaegertracing/jaeger-client-java/blob/f5f6ad1f4eaf606aba07562b7543958ec4658ebe/jaeger-core/src/main/java/io/jaegertracing/internal/propagation/TextMapCodec.java#L206) is URL encoding the HTTP header value before sending it over the wire. Then when the server receive the request and try to extract the span from it it will fail if `TextMap` format is used istead `HTTPHeaders` format. For example the java jaeger client will send something like this: `Uber-Trace-Id: 9ec076efd89825a%3A9c876c01059545b2%3Ab9ec076efd89825a%3A1` but the golang jaeger client is expecting this `Uber-Trace-Id: 9ec076efd89825a:9c876c01059545b2:b9ec076efd89825a:1` when the `TextMap` format is used. In this case the call results to the following [error](https://github.com/jaegertracing/jaeger-client-go/blob/master/context.go#L111): `String does not match tracer state format` Because the `http.go` file is used precisely for dealing with span in a HTTP context, I propose to default the span format to `HTTPHeaders`
Member
|
Thanks for the PR. Looks good to me so merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Today,
TextMapformat is used when injecting or extracing span from HTTP requests.This format will treat the HTTP header value (that contains the span) as is (without decoding). Conversely the
HTTPHeadersformat will try to URL decode the value first.The issue is that some opentracing clients like java jaeger client is URL encoding the HTTP header value before sending it over the wire. Then when the server receive the request and try to extract the span from it it will fail if
TextMapformat is used isteadHTTPHeadersformat.For example the java jaeger client will send something like this:
Uber-Trace-Id: 9ec076efd89825a%3A9c876c01059545b2%3Ab9ec076efd89825a%3A1but the golang jaeger client is expecting thisUber-Trace-Id: 9ec076efd89825a:9c876c01059545b2:b9ec076efd89825a:1when theTextMapformat is used.In this case the call results to the following error:
String does not match tracer state formatBecause the
http.gofile is used precisely for dealing with span in a HTTP context, I propose to default the span format toHTTPHeaders