0

Is there any way for Nginx to do 'slugification' of an incoming URL?

For example:

https://example.com/oldstuff/This%20Was%20An%20Actual%20App

to https://example.com/newsite/this_was_an_actual_app

I mean, I can do it with a big URL rewrite table, but I'd like it if Nginx can just do the slugification.

The other alternative would be to modify our app to take the 'oldstuff' URL and do the slugification internally, and do the redirect, but we don't have access to all of the new app's source code.

I've spent some time binging (actually, Startpage), but haven't found an Nginx or regex pattern to do this slugification conversion. It's not just replacing %20's with _, its the conversion to all lower case. Hmm ... maybe that's the way to do it, but I think that'll be a really hairy RegEx.

I didn't see 'to lower' or anything like it here, much less slugification: Guide on how to use regex in Nginx location block section? although it's a great guide nevertheless.

J. Gwinner
  • 931
  • 10
  • 15
  • 1
    Nginx cannot do the case conversion for you. There are some add-in languages such as Perl or Lua that may give you a solution. – Richard Smith Aug 04 '22 at 09:02
  • Thanks Richard. Based on your note, we looked for a different answer. With some debugging we found out we were dealing with a URI fragment. So my problem description wasn't completely accurate. See my answer below; I tried to give you credit as you pointed us in the right direction. – J. Gwinner Aug 05 '22 at 23:14

1 Answers1

0

I found a solution, which didn't involve NGinx, and fixed our problem.

I wasn't completely accurate with the problem description, but I'll leave it up. In our case, the actual URL was:

https://example.com/oldstuff#This%20Was%20An%20Actual%20App

Notice the hash. This is a "URI Fragment" and Nginx never sees it; the client handles it. So the part after the hash, which is the part that needed slugification, won't ever be seen by Nginx.

Our fix was to add a JavaScript onload function at "oldstuff" which then parsed the hash, and slugified the rest of the URI fragment. This then redirected correctly to the new site (which did NOT have a hash.) Fixed!

More detail:

https://en.wikipedia.org/wiki/URI_fragment

For the original problem description, what @Richard Smith said is probably the best fix, using something like JRS. We didn't have to implement this - which was good, as the Nginx configuration was machine generated in our case.

J. Gwinner
  • 931
  • 10
  • 15