Another .htaccess conversion problem with rewrites

Hello :slight_smile:

I’m trying to convert this part of a .htaccess file to caddy

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
and I’m currently using this rewrite rule in caddy

rewrite / {
        to {path} {path}/ /maintenance.html /index.php?q={path}&{query}{fragment}

I can’t spot my mistake but the underlying php application doesn’t behave like it did with apache.
Can you guys help me?

what behaviour do you expect and what behaviour are you getting instead ?

I’ve traced the problem down to leading slashes.
Apache gave the application $_REQUEST[‘q’] = ‘foo/bar/’
where caddy sets it to $_REQUEST[‘q’] = ‘/foo/bar/’

My current workaround is left trimming slashes inside the application. Is there a way to do this with caddy to fully clone the apache behaviour?

1 Like

Hmm, well that’s annoying (on Apache’s side) because the path is in fact /foo/bar/, not foo/bar/.

If we change this to strip the leading trailing slash, will that break anything? Or do we have to introduce a new placeholder…

I guess it could potentially break a lot of application if they use the path without input sanitizing as a condition like

if ($_REQUEST['q'] == '/foo/') {
} else if ($_REQUEST['q'] == '/bar/') {

Personally I wouldn’t strip the slashes because why should caddy clone apache’s mistakes?
[trump voice]Caddy isn’t intended to be a clone but a better webserver. Make the web great again![/trump]

…ehm… yeah. Excuse me


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.