Provide and extend `Server-Timing` header

[malud]

It would be a great addition if Couper provides the backend timings additionally to the existing log timings as Server-Timing header. Extending an existing Server-Timing header while chaining multiple gateways is also a valid use-case.

[filex]

Typically the request’s name is default. That would be boring. We could use the backend’s name to provide more useful info in the browser’s network inspector. Then it would be smth like api or print_service.

If an endpoint issues multiple requests, they need to have different names. Then, we could create a timing name from the backend and the non-default request name:

api  (omit redundant :default)
api:request2

[alex-schneider]

Do we need a config/setting flag for this feature? Or should Couper always send this header if a backend is used?

[filex]

We need to configure it. I would make it a boolean setting (cli flag, env, settings).

[johakoch]

Currently, the metrics may have a suffix (_[0-9a-f]{6}), which is unique, ok. But it's not possible to identify the position in a sequence of couper layers. Better use numbers, again.

Another idea: Instead of suffixes, use prefixes, as Chrome seems to sort Server Timings in the Timing tab.

[filex]

How can couper know in which position in a sandwich it is in? Or do you mean request sequences in a single endpoint?

[alex-schneider]

The last Couper instance (from client direction) would not have a prefix (or a prefix with the smallest digit).

client <- 2_metric <- 1_metric <- metric

[filex]

I don't think that we need to have those prefixes. if you have a sandwich with multiple coupers and services inbetween, I would hope that the backend-names are distinguishable.