zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From José Carlos Chávez <jcchav...@gmail.com>
Subject Re: headers in response
Date Sat, 15 Dec 2018 17:58:36 GMT
Just my 2p:

We have some E2E automatic tests on CI for some framework libraries and one
day Adrian suggested that we could pass the traceID on beforehand and then
check traces are actually instead of them being generated, we have
something like that in our E2E automated tests at my company so instead of
trying to get the traceID we generate them in the test.

Den lør. 15. des. 2018, 17:24 skrev Andriy Redko <drreta@gmail.com:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message