Return version header
In what area(s)?
/area networking
Describe the feature
Knative serving could return a header indicating the version that served the request
Hi - I wanted to clarify what do you mean by version - do you want the revision name?
Also for my curiosity - what's your use case and why do you want this information?
/triage needs-user-input
We do support routing based on a header https://github.com/knative/docs/tree/main/code-samples/serving/tag-header-based-routing
@dprotaso Sorry for the late reply, tag header based routing is exactly why we are asking this feature, when you do a call without indicating the header you don't know what version is serving the request.
So my proposal is to edit istio VirtualServices generated by knative in order to include a response header (like Knative-Serving-Tag) indicating the revision that served the request
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue or pull request is stale because it has been open for 90 days with no activity.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close
/lifecycle stale
/remove-lifecycle rotten
I'm going to close this out based on the comment from: https://github.com/knative/serving/issues/13476#issuecomment-1334642303
Revision name should probably be considered "customer data" and not be returned by default in HTTP responses.
Apps can do this themselves - we expose the names via the following env vars
https://github.com/knative/serving/blob/66c28b63a8114d08d302d0164d4d195b76cd9181/test/types/runtime.go#L36-L38