# Many shared-hosting PHP setups (CGI/FastCGI — this app targets Hostinger,
# per SMTP_HOST in .env.example) strip the Authorization header before PHP
# ever sees it. This restores it as HTTP_AUTHORIZATION, which
# api/v1/_bootstrap.php's api_authenticate() reads. Harmless no-op on setups
# (like local XAMPP/mod_php) that already pass it through natively.
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

# Extensionless URL rewriting (/auth/login -> auth/login.php), duplicated
# from the project root .htaccess rather than inherited from it — mod_rewrite
# per-directory processing uses whichever .htaccess is closest to the
# requested path, and does NOT chain a subdirectory's rules on top of its
# parent's. Since this file already exists here (for the Authorization
# header fix above), it silently shadowed the root .htaccess's rewrite
# rules for everything under api/ — meaning every api/v1/* endpoint 404'd
# under real Apache despite working under both PHP's built-in server
# (which ignores .htaccess entirely) and curl calls made with an explicit
# .php extension, which is why this went unnoticed until a real device hit
# a real Apache instance. Kept byte-for-byte identical to the root's
# equivalent rules so the two can't quietly drift apart again.
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^([^/.]+)/?$ $1.php [L,QSA]

RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.+)/?$ $1.php [L,QSA]
