Special redirects - placeholders: Is it expected that ORIGINAL_PATH includes "/"?

[sravenscroft]

Documentation reference: https://shlink.io/documentation/advanced/special-redirects/

The {ORIGINAL_PATH} includes a slash at the start.

E.g.
Invalid Short URL: https://shlink.example.com/invalidPath
Using this invalid short ULR redirect: https://www.example.com/?s={ORIGINAL_PATH}
Will redirect the user to https://www.example.com/?s=%2FinvalidPath

The "%2F" is a "/" character that is encoded.

Is this the intended behavior, and if so, is there a way to configure it not to include the slash in the ORIGINAL_PATH?

[sravenscroft]

To clarify - the expectation was to redirect to https://www.example.com/?s=invalidPath

• i.e. without the %2F

This issue was observed on version 3.7.3

[acelaya]

This is the intended behavior, yes. The {ORIGINAL_PATH} placeholder is always replaced with the full path, which always starts with a /.

Is that causing any problem?

[sravenscroft]

Thank you for your prompt reply and for confirming the intended behaviour of the {ORIGINAL_PATH} placeholder. I appreciate the clarity.

However, I’d like to clarify the issue I’m encountering with this functionality, as it impacts the use case I’m working with. In my scenario, I’m utilising the Shlink short URL to redirect to a WordPress site, specifically directing the {ORIGINAL_PATH} content as a search query parameter. The challenge arises because the encoded forward slash (%2F) at the beginning of the {ORIGINAL_PATH} is being interpreted as part of the search term itself rather than as a delimiter or ignored character.

For instance, when a user visits an invalid short URL like https://shlink.example.com/invalidPath, it redirects to https://www.example.com/?s=%2FinvalidPath instead of the expected https://www.example.com/?s=invalidPath. This inclusion of %2F alters the search term on the WordPress site, leading to unintended search results and a less-than-optimal user experience.

Is there a way to configure Shlink or a workaround to prevent the leading slash (/) from being included and encoded in the {ORIGINAL_PATH}? Such a capability would greatly enhance the flexibility and applicability of Shlink for scenarios like mine, where the leading slash can interfere with the intended functionality of the redirected URL.

Thank you for considering this issue. I'm looking forward to hearing your thoughts or suggestions on a possible solution.

Perhaps adding another placeholder (e.g. {SLUG}) that does not include a / will be the most elegant solution.

[acelaya]

The placeholders are designed to pass extra information that the redirected site can process, parse and use as needed.

The ORIGINAL_PATH one specifically needs to include the full path, otherwise it would be unintuitive and inconsistent with its name.

That said, I'm not completely sure if what's causing issues to you is the presence of the leading slash, or the fact that it is URL-encoded (or both).

Regardless of that, what you are describing is a very specific use case, where removing just the leading slash would not completely solve your problem.

What if someone visits https://shlink.example.com/invalid/path/with/more/segments? In this case, all the slashes in the path would be included, and URL-encoded.

Let's suppose Shlink implemented support for the SLUG placeholder, which is the same as the ORIGINAL_PATH, but removing the leading slash, and that you are only enabling invalid_short_url redirects, because that's all you care about. You could still have people visiting URLs with a single segment that includes special characters that need to be URL-encoded.

So the best option is that you redirect to an intermediary page that reads the query param, passes and processes it as needed, and then redirects to the search page.