htaccess on LiteSpeed: what carries over from an Apache host

Your existing rewrite rules keep working when you arrive here, which is the main reason moving from an Apache host does not require rewriting anything. A few directives behave differently, and they are all in the same area: caching and compression, where the server now does the job the rules used to ask a module to do.

What carries over unchanged

  • Rewrite rules and conditions, including everything a content management system writes for permalinks.
  • Redirects, whether written by hand or generated by a plugin.
  • Access control by address, and password protection.
  • Custom error document declarations.
  • Directory index preferences.

In practice this covers the entire contents of a typical site's file, which is why migrations are uneventful.

Where the difference shows up

Directives that configure a caching or compression module are the exception. Rules written for a PHP based caching plugin, or blocks that set expiry headers through a module, may be ignored or superseded because the server handles that layer itself.

This is a feature rather than a compatibility problem: caching decisions made inside the server happen before the request reaches the application, which is earlier and cheaper than any rule can manage. The reasoning is in Speed and Caching.

The migration cleanup worth doing

After moving a site, read the file rather than assuming. Sites that have lived on several hosts accumulate layers, and the usual finds are:

  1. Blocks from a caching plugin no longer installed. Harmless but confusing, and they make future debugging slower.
  2. Rules referencing an old absolute path. The path changed with the account and the rule now points nowhere.
  3. Duplicate permalink blocks. Two content management installs each wrote their own, and only one is doing anything.
  4. Security rules from a plugin that was removed. These can silently block legitimate requests years later.

Remove them one at a time, testing between each. Do not clear the file wholesale, because the permalink block is load bearing and the site returns nothing but 404s without it.

Rules are per site, not per account

The file sits in the site's own directory, so on an account holding several sites each has its own. That is worth knowing in both directions: a rule added at the account root affects every site under it, and a rule that fixed one site does not automatically protect its neighbours.

If you are applying a rule across a network, apply it deliberately per site rather than assuming a shared inheritance, and note it somewhere so the next person understands why one site differs.

When a rule is the wrong tool

Two things get pushed into rewrite rules that do not belong there:

  • Bot blocking by user agent. Trivially spoofed, and the list grows forever. Rate limiting and address level controls are more effective.
  • Caching logic. The server already does this properly, and hand written cache rules mostly create inconsistency between sites.

Testing changes safely

A syntax error in this file takes the whole site down immediately, not gradually. Keep a copy before editing, change one thing, load a page, then continue. On a network, apply the change to one site and use it for a day before rolling it out, as described in Running Your Estate.

The server documentation is at docs.litespeedtech.com. For moving a site here in the first place, see Moving In.

Still not sure which way to go?

Tell us what you are building. If it needs less than you think, we will say so.

Talk to us · 24/7/365