Do server variables allow unencoded slashes?

This is somewhat related to #2204 and https://github.com/OAI/OpenAPI-Specification/pull/2218. It’s been clarified that path parameters don’t allow unescaped slashes, but what about server variables?

Consider this example:

servers:
  - url: "https://example.com/{subpath}reports/"
    variables:
      subpath:
        default: ''
        enum:
          - ''
          - 'abc/123/'
          - 'abc/456/'

Are these valid values for a server variable? If yes - what is the resulting server URL for subpath=abc/123/? –

https://example.com/abc/123/reports/
 or
https://example.com/abc%2F123%2Freports/

In other words, is the example above a proper way to vary subpaths using server variables, or should this example be rewritten as follows? –

servers:
  - url: "https://api.example.com/reports/"
  - url: "https://api.example.com/abc/{id}/reports/"
    variables:
      id:
        default: ''
        enum:
          - '123'
          - '456'

[darrelmiller]

@awwright By the tooling providing the parameter value. The reference you quoted in RFC3986 is a good one and might warrant us adding words that indicate a server variable should not be treated as a “data octet” but as a literal portion of the URL.

[darrelmiller]

The limitation on path templates is to prevent ambiguous resolution of operations. e.g.

/reports/foo/bar
/reports/{someparam}    where someparam = foo/bar

In the case of server variables mapping to a different server URI does not have significant consequences. However preventing a a forward slash in a server variable would prevent multi-segment variable values. e.g.

/{tenantName}/mysaasresource

/cocacola/us/mysaasresource
/cocacola/uk/mysaasresource

If forward slashes are not intended to create path segments in the URL then the need to be a percent encoded.

Nobody raised an objection to this in the TSC call because Marsh was missing 😃 Hence the current wording of the spec is sufficient.