No way to describe a path-item with an empty URI path

[karenetheridge]

@ralfhandl said in this thread that URLs with trailing slashes can be treated differently than those without... but we have no way of expressing that at present, as all entries under /paths must be prefixed with a slash (https://spec.openapis.org/oas/v3.1.1#patterned-fields). Is this something we want to be able to express?

[handrews]

@karenetheridge all must be prefixed with a slash, but there's no restriction on suffixing so I feel like I'm missing something here? Can you show an example of what sort of URL distinction can't be made right now? I think that this would work:

paths:
   /foo: # without trailing slash
   /foo/: # with trailing slash

AFAIK, the only thing you can't model is the bare hostname URL with an empty path component. Your path component in the OAS is always at least '/' because of the leading slash requirement (and that assumes a server URL with a completely empty path component).

[karenetheridge]

Yes, I'm talking about a URI like https://example.com with no trailing slash, and therefore the path component is the empty string. We have no way of modeling that right now; in my implementation I assume empty string is / and then look for a path-item entry at /paths/, but that's reading something into the spec that isn't there right now.

https://example.com/foo and https://example.com/foo/ aren't the same URI and MAY be treated identically by a server (I have seen web frameworks that turn one into the other before application code gets its hands on it), but they are treated as separate /paths entries and I think we should continue to behave that way -- although some sort of global setting in an openapi document that said "silently strip trailing slashes from paths when doing path-item lookups" could be useful and would be consistent with those web frameworks that already behaved that way.

[karenetheridge]

To follow up... I dug into the RFCs to see how the path portion of the URI should be specified -- https://httpwg.org/specs/rfc7230.html#request-target, https://datatracker.ietf.org/doc/html/rfc9112#section-3.2.1

My reading of this is that the path form of the "request-target" portion of the HTTP message (on the "start-line") is that it MUST be prefaced with /, with the exception of the OPTIONS form of a request, where the request-target is *. (The other forms, absolute-form and authority-form, are out of scope for OpenAPI, I think.)

So perhaps we just need to amend the spec to allow for * for OPTIONS, at the same time as we allow for OPTIONS to be one of the methods (#1747) ? We could also clarify in the spec that the / prefacing is an RFC requirement.

[handrews]

I think you're right. BTW the newest RFC for that section is here: https://www.rfc-editor.org/rfc/rfc9112.html#name-request-target

We've previously declined to support OPTIONS * in #2316 (I have not read through the rationale yet).