zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andriy Redko <drr...@gmail.com>
Subject Re: headers in response
Date Sat, 15 Dec 2018 16:24:28 GMT
Hi Jordi,

We also do this in Apache CXF, for all our integrations. I don't
recall this feature being requested but it indeed helps to debug 
some issues. The presence of the trace headers in the response does
not hurt much I think (since they are present in request anyway). But
I don't have the proof it is useful actually yet.

Best Regards,
    Andriy Redko

JPC> Not particularly arguing we should do it in general. If most of the
JPC> implementations do not have this, means they did not encounter this problem.
JPC> Meaning, testers in my company are doing something unusual and we need to
JPC> rethink our side.

JPC> If other people are seeing this, that means the Ruby implementation is
JPC> behind and we should just implement it.
JPC> In the Ruby case it is simple as the middleware sits there for both request
JPC> and response. I'm not worried about the implementation being tough but if
JPC> it would be the correct thing to do.

JPC> As I said, there is no reason in production to need this. From upstream
JPC> services traces are already there. This is only an issue when you call
JPC> using Postman or other testing tool.


JPC> On Fri, Dec 14, 2018 at 10:03 PM Adrian Cole <adrian.f.cole@gmail.com>
JPC> wrote:

>> This topic has come up many times. Somebody named Jordi raise this
>> over 2 years ago I think :)

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openzipkin_b3-2Dpropagation_issues_4&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=0uNEtmQGBarTGjZm759EZIFgOHFjQAMAr_M2rfsOCl4&e=

>> The best solution I can think of is to have the user opt into a
>> response header. This is what kamon does and I think some libraries
>> could follow:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kamon-2Dio_Kamon_blob_master_kamon-2Dcore_src_main_resources_reference.conf-23L350&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=1XJFVwGQNbQynTx8Ws_o_16YdvyyCKyrXdb895wWVj0&e=

>> main downside besides leaking the ID is that most instrumentation are
>> not currently trying to mutate http response headers. At any rate, in
>> a lot of middleware someone can do this any way by adding a filter
>> that peeks at the current span.

>> hope this helps!
>> -A
>> On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jcarres@mdsol.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > Multiple times I've been asked in my company about adding the zipkin
>> > headers to responses.
>> >
>> > Mostly by testers who want to know and search trace ids in logs but they
>> > are doing some manual test and it is difficult for them to generate
>> unique
>> > ids and add them to the headers.
>> >
>> > As this is not a case that happens in real production environment, I
>> never
>> > wanted to do it.
>> >
>> > What do other libraries do? Is this something you can relate to?
>> >
>> > Thanks
>> >
>> > --
>> > *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
>> > <http://www.mdsol.com/>
>> > Api bundle: api-bundle@mdsol.com
>> > API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1

>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
>> For additional commands, e-mail: dev-help@zipkin.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org


Mime
View raw message