Get in Touch About a Rule That Misbehaves

One inbox, read by a person. No ticket numbers and no chatbot standing in front of it.

What to Include in a Bug Report

Email contact@htaccess.tools. A rule that misfires is usually easy to fix once it is clear which server it ran on, so a little detail goes a long way.

For a rule that does not work

If a block from the generator throws a 500, loops, or quietly does nothing, send:

Redirect loops are the common one, and they are almost always two rules disagreeing rather than one rule being wrong. Mentioning what else lives in the file helps.

Before you write in

Two checks solve most reports. First, confirm the rule is running at all: add a deliberate typo to the top of the file and reload. A 500 error means Apache is reading it, and no error means AllowOverride is switched off for that directory, which is a host setting rather than a bug here. Second, load the page in a private window. A cached 301 from an earlier attempt survives edits to the file and produces some very convincing false reports.

If both check out and the rule still misbehaves, that is worth an email. Include the error log line if you can reach it, since Apache names the exact directive it choked on.

For everything else

Ideas for options worth adding, corrections to anything written on this site, and questions about how a directive behaves all go to the same address. Requests that would need a server, an account or stored history get a friendly no, and the reasoning behind that is on the about page.

Replies usually go out within a few days. Please do not send passwords, .htpasswd files or live credentials: the hash generator runs in your browser precisely so those never need to travel, and how the rest is handled is written up in the privacy policy. Anything about liability for a rule that broke a site is covered by the terms of use.