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:

Server-Timing: emoji-svc;dur=27
Server-Timing: voting-svc;dur=34.4
Server-Timing: web-svc;dur=78.1

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.

Kevin


Oliver Gould <v...@...>
 

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.
2. It should not be enabled by default, since it poses an information leak to external users.
3. So, we'd need an authenticatable way to control how which requests have this header added.

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.

On Tue, Feb 13, 2018 at 11:29 AM Kevin Lingerfelt <k...@...> wrote:
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:

Server-Timing: emoji-svc;dur=27
Server-Timing: voting-svc;dur=34.4
Server-Timing: web-svc;dur=78.1

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.

Kevin

--
You received this message because you are subscribed to the Google Groups "conduit-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conduit-dev...@....
To post to this group, send email to condu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/conduit-dev/CAJX8Nx%2BmORJgpuPa%2BLB4_-y0Pc%2BPqP%3Dp6_-oVkACFijN9amQLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.