0

I work for an organization with a content management server that was newly switched to Apache. I don't know what it was running before, but I am unsure why the following is happening and how to fix it now that the switch has occurred. Let me show the problem:

URL 1: http://example.org/1234EN.pdf

URL 2: http://example.org/1234en.pdf

1234 is the number of a specific form and the EN (or en) portion denotes the language the form is in, in this case, English. The problem is that URL 1 goes to the specific form, but URL 2 doesn't go anywhere. To solve for this easy to make error, I don't want to create and have to maintain two versions of the same form, one for each URL, because the content of the form often changes and both versions would need then to be updated for each URL. Additionally, customers also don't want to own up to user error and some can't be convinced to type in the UPERCASE portion.

Is there a way to solve this problem? Redirects? Or is there a way to make Apache convert the lowercase suffix at the end go to the UPPERCASE version of the form?

HBruijn
  • 72,524
  • 21
  • 127
  • 192
catmandude
  • 1
  • 1

1 Answers1

3

Of CoUrSE iT mAkES liFE mucH eASIEr when YOu cAn IGnoRe CasE, tHe MeaNinG sTayS ThE SamE, RiGhT?

Historically: The Windows FAT32 file system for instance preserved the case but was case insensitive and when opening a file you don’t have to use same case as which was used to create the file, unlike in Linux. In lLinux you have to use the exact case.

But you can use the aptly named Apache mod_speling to adapt Apache behave as if the filesystem is case insensitive https://httpd.apache.org/docs/2.4/mod/mod_speling.html

<Directory /var/www/html>
    CheckCaseOnly on
    CheckSpelling on
</Directory>
HBruijn
  • 72,524
  • 21
  • 127
  • 192