use `KONG-` prefix for Kong specific headers where applicable.

[ahmadnassri]

X- prefixes have been deprecated since RFC 6648 along with a set of reccomendations for creating new parameters:

3.  Recommendations for Creators of New Parameters

   Creators of new parameters to be used in the context of application
   protocols:

   1.  SHOULD assume that all parameters they create might become
       standardized, public, commonly deployed, or usable across
       multiple implementations.

   2.  SHOULD employ meaningful parameter names that they have reason to
       believe are currently unused.

   3.  SHOULD NOT prefix their parameter names with "X-" or similar
       constructs.

since Kong specific headers prefixed with X- depict new and common patterns of API Management usage, we can start with Kong- prefix, or even API- 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)

[thibaultcha]

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...

[ahmadnassri]

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

[thibaultcha]

Well I think the least worst is Service...

[nijikokun]

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).

[subnetmarco]

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.

[ahmadnassri]

@thefosk we can:

1. make it configurable
2. introduce a fallback for the interim version in which this is released (so, we'd be sending both X- and Kong-)
3. remove the fallback in the next version after the one that introduces this change.

[Tieske]

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.

[thibaultcha]

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-".

[ahmadnassri]

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.

[thibaultcha]

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.

[Tieske]

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.

[thibaultcha]

Yes, and yes.