@fantasticfears I am reopening this cause this needs urgent polish (in fact make this your #1 priority)
Issues I have:
If a topic has the test งಠಠง and slug generation method is “encoded” the slug is test-งಠಠง. This is a nasty problem cause the actual UI will cause a fight with the browser. The browser sends over the slug as test-%E0%B8%87%E0%B2%A0%E0%B2%A0%E0%B8%87 and we perform no decoding on our side which leads to an infinite redirect in the topic page, if you hit reload. It feels to me like “encoded” should be always percent encoded.
If you change slug generation method there is no way of “fixing” the slug cache in “topics” table. There needs to be some mechanism of clearing out the “slug” column on topics. Maybe if you touch that setting it should automatically null out all cached slugs on topic.
As it stands we are seeing some extreme issues here with infinite redirects and there is not clean way of correcting the customer issues.
OK, I’ve researched into Rails router, Rack and Webrick. According to previous dev discussion, I am sure Rails conforms to Rack behaviour. This might not be ideal for us. Though I didn’t check, I have some confidence to say that Puma and Unicorn don’t escape non-ascii for URI. In contrast, Webrick does conforms to this point but it pins the uri into US_ASCII. It would be a complicated debug process to hunt down the cause. It might be regexp failure, encoding problem for Rails router GTG.
My step would be:
Escape our Slug detector fast to fix urgent problem.
Find a place to report this problem or write PR. I am not familiar with Rails community. I would like to ask for your direction later.
Sure, but we also need to make sure we deal with history AND switching slug generation mechanisms. Both are critical we deal with. When you switch mechanisms on categories it is particularly complicated cause we allow overrides.