Add "format" to the policy configuration definition to allow validation
Adding "format" to the JSON schema of the policies would be useful to allow validation.
So, for example, if there is a "url" required in a policy, the UI for configuring this policy can validate the user input.
Reference: http://json-schema.org/latest/json-schema-validation.html#format
@mayorova to which policies?
Policy configuration is defined by JSON schema: https://github.com/3scale/apicast/blob/master/gateway/src/apicast/policy/manifest-schema.json
And individual policies have own JSON schema for the config: https://github.com/3scale/apicast/blob/master/gateway/src/apicast/policy/url_rewriting/apicast-policy.json
@mikz Any policy really, the idea is to have this included into the policy configuration JSON schema, then any policy can use it.
For example, the url config parameter for the upstream policy – I think a validation for the values of this parameter would be nice.
@mayorova Then you can add "format": "uri" there and close this issue?
@mikz but then it also needs to be added to https://github.com/3scale/apicast/blob/master/gateway/src/apicast/policy/manifest-schema.json, right?
Btw, specifically in case of upsteam policy "format": "uri" is not exactly correct. The policy expects https?://host:port, and uri also can have path and queryparams...
@mayorova no. That one just says every policy has to have valid JSON schema for configuration.
And upstream policy can totally work with full URI: https://github.com/3scale/apicast/blob/6cf9b4a75026faab48b0a799c86d41616d232819/gateway/src/apicast/policy/upstream/upstream.lua#L17-L26 It will override path if you include it in the URI. If you want to spend time doing valid regex that covers all the cases and maintain it then go ahead. Validations do not have to be so strict, because then they can require a lot of maintenance cost for edge cases.