Kong: Kong Service Resource URI Validation Error?

[jeremyjpj0916]

Summary

Seems Kong throws a schema violation error on URI's with a $ in them? Is this not a valid URL?:

http://my-api.company.com/R4/Bundle/$consultation-submit

Service Resource:

{
  "host": "my-api.company.com",
  "created_at": 1593734424,
  "connect_timeout": 2000,
  "id": "7be474e8-02c3-4787-9450-09a43540649c",
  "protocol": "http",
  "name": "optum.ocm.advisor.stage.optum.ocm.telemedService.dmz.v1",
  "read_timeout": 9000,
  "port": 80,
  "path": "/R4/Bundle",   ---> can't add the /$consultation-submit here
  "updated_at": 1593734424,
  "retries": 0,
  "write_timeout": 9000,
  "tags": null,
  "client_certificate": null,
  "extras": {}
}

Kong throws a schema violation error:

'/R4/Bundle/$consultation-submit' (characters outside of the reserved list of RFC 3986 found))

Related:
https://stackoverflow.com/questions/1856785/characters-allowed-in-a-url

Steps To Reproduce

1. Try to create a Kong Service resource with $ in the URI

Additional Details & Logs

• Kong version 2.0.5

[bungle]

Thank you for reporting this. Let’s see what is proper solution.

[jeremyjpj0916]

I think this validation must be a newer thing w Kong too because I am positive we have a few proxies on Kong from prior versions that were made with a dollar sign present in uri’s for some kind of FIHR api format standard. From what I can tell $ is not a character that needs uri encoding or anything special. Thanks!

[hishamhm]

So, after a quick investigation in RFC 3986 (and its updates and erratas), this is indeed a bug, for $ is valid in the path segment of URIs. These are the relevant grammar rules (the only parts of RFCs I really trust because they're written in unambiguous language :laughing: ):

      reserved    = gen-delims / sub-delims

      gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

      sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

      path          = path-abempty    ; begins with "/" or is empty
                    / path-absolute   ; begins with "/" but not "//"
                    / path-noscheme   ; begins with a non-colon segment
                    / path-rootless   ; begins with a segment
                    / path-empty      ; zero characters

      path-abempty  = *( "/" segment )
      path-absolute = "/" [ segment-nz *( "/" segment ) ]
      path-noscheme = segment-nz-nc *( "/" segment )
      path-rootless = segment-nz *( "/" segment )
      path-empty    = 0<pchar>

      segment       = *pchar
      segment-nz    = 1*pchar
      segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                    ; non-zero-length segment without any colon ":"

      pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

Indeed "$" is part of reserved as part of sub-delims, but the path rule includes segment and segment-nz, which include pchar, which includes sub-delims explicitly.

Long story short, all characters from the sub-delims list above need to be added as valid to our path validator!

[jeremyjpj0916]

@hishamhm good to know that the FIHR api standard that some internal team here is implementing does not go against HTTPS URI's allowed chars 😄 . Would not be the first time I have seen folks do bad things though so I thought to check in here. Thanks for looking into it.

[jeremyjpj0916]

@hishamhm would this be a 2.1.1 kinda fix as well? I don't think easing validation limitations would be breaking so it could come on a minor patch (along with that admin api bug we spotted)?