Another .htaccess conversion problem with rewrites

[Robert]

Hello

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?

[abiosoft (Abiola Ibrahim)]

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

[Robert]

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?

[matt (Matt Holt)]

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…

[Robert]

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/') {
     do_foo_stuff();
} else if ($_REQUEST['q'] == '/bar/') {
    do_bar_stuff();
}

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