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
The easiest solution is to simply prevent placeholders from appearing before the '?' (so they have to be in the query or fragment). This is a bit restrictive but may be the only reliable method. Perhaps a more targeted solution is to say that it's illegal to have a placeholder in a path segment by itself, so you could have "/foo-{text}" but not "/{text}".
Related to #25, because if we banned placeholders in the path, we could reliably resolve the URL template at parse time.
The text was updated successfully, but these errors were encountered:
Consider a manifest with:
If the third-party app supplies text "..", it would allow the sharer to path-escape and direct the user to URLs that the share target never intended.
It's not clear how to resolve this; escaping '.' to "%2e" doesn't help because the URL Standard explicitly says that "%2e%2e" also means parent directory.
The easiest solution is to simply prevent placeholders from appearing before the '?' (so they have to be in the query or fragment). This is a bit restrictive but may be the only reliable method. Perhaps a more targeted solution is to say that it's illegal to have a placeholder in a path segment by itself, so you could have "/foo-{text}" but not "/{text}".
Related to #25, because if we banned placeholders in the path, we could reliably resolve the URL template at parse time.
The text was updated successfully, but these errors were encountered: