Supporting Forward Slashes as the end of a short URL

[bhelmick]

Greetings! I have what seems to me an odd situation. I am running YOURLS v1.9.3 with the plugin "Allow Forward Slashes in Short URLs" enabled . It's working mostly successfully. Any short URL that has forward slashes works fine, except for one scenario. When a short URL ends with a forward slash, YOURLS completely fails to resolve the URL at all. It's almost as if ending with a slash is passing it to Apache whereas a slash within the origin URL is handled by YOURLS.

Here are a couple examples:
URL will fail with a 403: https://1ed.tech/spec/clr/v1p0/schema/openapi/
URL succeeds in redirecting: https://1ed.tech/spec/clr/v1p0/schema/json

Notice the successful one does not end with a forward slash but does contain them. The failing one contains forward slashes, but also specifically ends with one. Here is a screenshot from the admin so you can see these two URLs and how they're set up.

My goal here, as you might imagine from the structure of my short URLs, is to fully emulate a path in YOURLS and forward to a long URL. The only thing on this domain is YOURLS so I will never need to care about the actual path of anything other than /admin.

I figured I'd start with the Plugins discussion area because it could be an artifact of this plugin and not an artifact of YOURLS itself. It could also not be YOURLS fault at all but some kind of behavior in Apache. I'd love to find a clever way to either fork the plugin and update or perhaps explore a workaround in .htaccess if it's Apache.

[dgw]

Based on the examples I can see in your screenshot (the 3/4 that are shown in full), it looks like you might not even need YOURLS for this use case.

For example, you could create a rule in Apache that just takes everything under 1ed.tech/spec/(.*) and redirects to purl.imsglobal.org/spec/$1.

That could even work if there is some real content in 1ed.tech/spec, using the same "file or directory with this path doesn't exist" rewrite conditions that YOURLS uses.

For anyone to troubleshoot your rewrite rules, though, you'll have to share the .htaccess contents.

---

For completeness, I should note that the plugin you're using is marked as archived, meaning its author will no longer maintain it. Fortunately, it's simple enough that it shouldn't break any time soon. And because of that simplicity, I'm confident that the problem you observe is entirely unrelated to the plugin. It does nothing more than add / to the characters YOURLS allows in link keywords. (Any character not in the allowed list is removed when "sanitizing" keywords.)

[bhelmick]

First, thanks so much for the quick reply!

Indeed, dgw, in the snapshot I provided, you are correct that I wouldn't need YOURLS. Let me give just a touch of backstory and the use cases of why I'm looking for this particular solution.

Many years out, our non-profit established a PURL server for doing just that, creating a persistent URL location for redirecting to resources. Unfortunately over time, some folks decided to actually store content on that server in addition to providing redirections. Now that I've joined the organization, I want to change that and return this to being a true PURL environment. But, because I want to respect the intention of a persistent URL, I need to support path like characters in the document IDs. I then want to move all the content off that old server to a new dedicated library and use YOURLS to perform the redirections. There are many thousands of documents/redirections on that old server so the .htaccess file would need to be quite large.

My second use case is I wish to use the GUI interface of YOURLS to allow non-technical folks to maintain the long URLs over time. The interface in YOURLS is super friendly and lightweight which makes it a perfect tool for everyone to use. Manipulating an .htaccess file would of course still work, but you do need to be technically inclined to do so. With YOURLS, I use the Google Auth plugin to give my entire org access to the GUI.

I hope these uses cases explain why I'd still like to push forward with YOURLS and try to solve the core problem. I think you've nailed it that the plugin isn't the issue. My gut tells me it's likely Apache. I'm just not sure how to make it not care about the trailing slashes.

Thanks again for your insight.

[bhelmick]

I'm getting closer to a solution. What I did was disable Apache's default behavior with mod_dir. Then, I added an explicit Directory command adding that behavior back for /admin. If I then remove the trailing slash from the short URL in YOURLS, then the URL https://1ed.tech/spec/clr/v1p0/schema/openapi and https://1ed.tech/spec/clr/v1p0/schema/openapi/ both are handled by YOURLS properly and redirected. Apache now effectively ignores the trailing slash meaning anything that includes it just doesn't care; therefore, the short URL can't have a trailing slash so YOURLS can recognize it properly.

For completeness, here is my dir.conf form /etc/apache2/mods-enabled
<IfModule mod_dir.c>
#DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
DirectoryIndex disabled
DirectorySlash off
</IfModule>

And the apache2.conf that defines the base path to YOURLS
<Directory /var/www/html/admin>
DirectoryIndex index.php
</Directory>

What I think would be good is to fork the allow forward slash plugin and update it to remove trailing slashes but leave all others present. But before I undertake that, I'd love your feedback on the above solution that it would be proper to proceed this way and highlight any problems I'm not contemplating by doing the above.