The ClientSpecifiesVersionInHeader type provides an implementation of DynamicVersionPolicy which allows for versioning APIs according to an HTTP header. Currently ClientSpecifiesVersionInHeader does not add the specified version header to the Vary response header. This means that if a Dropshot server ends up behind a caching proxy, the proxy has no way of knowing that the response body can only be re-used for requests with the same version header set, meaning that clients instead end up getting responses for API versions that they don't support.
It's not entirely clear to me how best to resolve this, but presumably the DynamicVersionPolicy trait would need to provide a way of setting at least the Vary header for responses. It might make sense to allow setting any header though, which would allow for e.g. returning the requested version as a response header as well, meaning that the response would be more self-describing.
The
ClientSpecifiesVersionInHeadertype provides an implementation ofDynamicVersionPolicywhich allows for versioning APIs according to an HTTP header. CurrentlyClientSpecifiesVersionInHeaderdoes not add the specified version header to theVaryresponse header. This means that if a Dropshot server ends up behind a caching proxy, the proxy has no way of knowing that the response body can only be re-used for requests with the same version header set, meaning that clients instead end up getting responses for API versions that they don't support.It's not entirely clear to me how best to resolve this, but presumably the
DynamicVersionPolicytrait would need to provide a way of setting at least theVaryheader for responses. It might make sense to allow setting any header though, which would allow for e.g. returning the requested version as a response header as well, meaning that the response would be more self-describing.