You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using a route generated like that results in an invalid route: it doesn't match /v1/docs, but actually /v1/%2Fdocs (%2F, the urlencoded slash) - that's because SwaggerAkka is using pathPrefix(path) which accepts a PathMatcher, to which the string is converted as an entire segment.
When you go to /v1/%2Fdocs, however, you get a redirect to /v1/docs/index.html?url=/v1/docs/docs.yaml, which is still incorrect:
This has been encountered by @CucumisSativus, so credits to him for finding this issue ;)
I think the simplest fix would be to either:
accept some PathMatcher[...] instead of a String (might be weird in types, haven't tried though)
not accept any string at all and create a route on the root level, thus requiring users to wrap the whole thing in a pathPrefix of their own
accept a list of segments and concatenate them with the right / operator.
I would personally opt for option 2, as it's the most flexible anyway. The existing implementation could be left as a deprecated overload for a while, then removed maybe in 0.17 or 1.0.
The text was updated successfully, but these errors were encountered:
Tapir version: 0.16.10
Scala version: 2.12.12
Describe the bug
Using a route generated like that results in an invalid route: it doesn't match
/v1/docs
, but actually/v1/%2Fdocs
(%2F
, the urlencoded slash) - that's because SwaggerAkka is usingpathPrefix(path)
which accepts a PathMatcher, to which the string is converted as an entire segment.When you go to
/v1/%2Fdocs
, however, you get a redirect to/v1/docs/index.html?url=/v1/docs/docs.yaml
, which is still incorrect:How to reproduce?
then hit
localhost:8080/v1/docs
in your browser.Additional information
This has been encountered by @CucumisSativus, so credits to him for finding this issue ;)
I think the simplest fix would be to either:
PathMatcher[...]
instead of a String (might be weird in types, haven't tried though)pathPrefix
of their own/
operator.I would personally opt for option 2, as it's the most flexible anyway. The existing implementation could be left as a deprecated overload for a while, then removed maybe in 0.17 or 1.0.
The text was updated successfully, but these errors were encountered: