Conduit support for Server-Timing headers?
Kevin Lingerfelt <k...@...>
Would it be useful for the conduit proxy to start adding Server-Timing headers to HTTP responses?
For instance, given the emojivoto demo, when conduit proxies a request to the web service's /api/vote endpoint, the response could include the following headers:
Or... something like that. If we do send back this timing information, then some browsers could display it natively in their suite of developer tools, like so.
Note that the example above requires that the web service attaches any Server-Timing headers that it receives from outbound requests to the outbound response that it sends back to the client. Given that this feature requires application participation to propagate headers, it might be better to pursue a full tracing implementation instead. But I at least wanted to put it out there for discussion.
Oliver Gould <v...@...>
toggle quoted messageShow quoted text
This definitely sounds like a nice feature enhancement, but we'll need the authentication and policy stories to be a bit further along before this feature is practical.
3. So, we'd need an authenticatable way to control how which requests have this header added.
2. It should not be enabled by default, since it poses an information leak to external users.
I quite like this idea, but I have a few general concerns:1. It requires application change, and it will may get unwieldy to instruct applications of what headers they are expected to forward.
On Tue, Feb 13, 2018 at 11:29 AM Kevin Lingerfelt <k...@...> wrote: