Closed ahmadnassri closed 3 years ago
I am fine with replacing X-
with Kong-
, however that doesn't feel very "white-label" to providers using Kong on premise. Should we go for API-
maybe? That doesn't feel very right either...
that's what I was referencing in using a more generic name (so we can later even introduce as standard to the rest of the API community)
options that come to mind:
Proxy
API-Proxy
Admin
Service
Well I think the least worst is Service
...
By default Kong-
and for white-label allow custom name prefix for header, so I could change it to Mashape-
if I wanted.
Mostly relying on this note below the text that @ahmadnassri posted:
Note: If the relevant parameter name space has conventions about
associating parameter names with those who create them, a parameter
name could incorporate the organization's name or primary domain name
(see Appendix B for examples).
Just want to point out that this change would be a breaking change and our users will need to update their implementations - not sure it's worth it.
@thefosk we can:
X-
and Kong-
)use option 1, also works best for white-label
on premises. Then break it by setting the new default to Kong-
and document how to configure it the way it was before if needed.
I have been thinking about making this configurable in the datastore, so all nodes can be aware of it (instead of the configuration file), and this could be configurable on a per-API basis. Maybe as an attribute of the "Services" entity, which would default to "Kong-".
I would actually disagree on making this configurable per API, seems like a core functionality of the system and especially concerning SDKs and integrations.
e.g. an SDK library dealing with requests from Kong now has to be aware of each API/route prefix for headers...
therefore I think it should remain a global setting.
This is a non-sequitur. If the SDK is developed by the same company, then said company can just have the same prefix for all of its APIs. If the SDK is developed by a third party, then the same problem arises since we are making it configurable anyways. One company might have 2 services and want them to be considered separated from a user perspective, hence not the same prefix. Finally, an SDK could simply make this configurable if ever needed.
I have been thinking about making this configurable in the datastore, so all nodes can be aware of it (instead of the configuration file)
shouldn't the entire config be stored in the database? (only db access info and credentials locally provided)
e.g. an SDK library dealing with requests from Kong now has to be aware of each API/route prefix for headers... therefore I think it should remain a global setting.
I don't think you should punish a power-user for the stupidity of some fool. Even if you don't provide this flexibility, the fool will find another way to mess up his config.
Yes, and yes.
X-
prefixes have been deprecated since RFC 6648 along with a set of reccomendations for creating new parameters:since Kong specific headers prefixed with
X-
depict new and common patterns of API Management usage, we can start withKong-
prefix, or evenAPI-
prefix to give it more meaning.as we make our way into standardizing these headers as common practice, we can suggest them as an RFC to IETF in the future.
Proxy specific headers should remain intact, or apply existing standards where applicable (such as in #270)