Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Our APIs use header versioning with a custom header name, x-ourcompany-api-version. We were able to easily achieve this using the tools available in this library.

This x-ourcompany- header prefix convention applies to many of the headers we emit/consume generally, but particularly to the supported/deprecated API version headers. At present, those header names are hard-coded into the DefaultApiVersionReporter:

This required us to provide our own custom IReportApiVersions implementation. It's a nearly verbatim copy of the DefaultApiVersionReporter that reads the header names from options instead. I also have to take care to register/replace the service as well.

Describe the solution you'd like

I propose that the api-supported-versions and api-deprecated-versions header names be read from options, defaulting/falling-back to the existing constants.

For example, perhaps something akin to:

builder.Services.AddApiVersioning(options =>
{
    // reporting api versions will return the headers
    // "api-supported-versions" and "api-deprecated-versions"
    options.ReportApiVersions = true;
    options.SupportedVersionsHeader = "x-custom-api-supported-versions";
    options.DeprecatedVersionsHeader = "x-custom-api-deprecated-versions";
});

Additional context

The obvious work around is to continue with our custom implementation. This is really heavy handed considering we only need to customize the header names. It also suffers from the fact that it doesn't automatically receive updates to the source material (suppose the writing of the sunset policy or optimizations to the header output changes).

Perhaps if the class weren't sealed it could have virtual members for either retrieving the header names or writing the headers, though the latter would work best with a change in accessibility of AddApiVersionHeader (which might actually be useful on its own). This would at least make is easier for us to customize the behavior without needing to reimplement the entire class if new options are deemed undesirable.