می‌خواهیم نشانی قدیمی به نشانی تازه برود و مسیرهای یک برنامه به ورودی اصلی آن برسند. این دو کار رفتار متفاوت دارند: redirect از کلاینت درخواست تازه می‌خواهد؛ rewrite می‌تواند داخل سرور انجام شود.

این جلسه بخشی از دورهٔ آپاچی در ۵۰ شب است. قرارداد نام‌ها، مسیرها و روش اعمال تغییر را در راهنمای دوره بخوان.

محیط: www روی HTTP، ماژول‌های alias و rewrite فعال؛ هنوز redirect عمومی HTTPS اضافه نشده است.

هدایت ساده و قابل بازگشت#

داخل VirtualHost:

RedirectMatch 302 ^/old$ /new

302 برای آزمایش موقت است؛ 301 دائمی ممکن است در مرورگر cache شود. با curl -I، Location: /new یا نشانی کامل معادل را بررسی کن. به‌صورت پیش‌فرض curl redirect را دنبال نمی‌کند؛ -L درخواست‌های بعدی را هم می‌فرستد.

برای مسیرهای برنامه، در یک سایت جدا با index.php اجراشدنی از درس‌های PHP، الگوی front controller یعنی «یک ورودی مشترک برای مسیرهای مجازی» چنین است:

<Directory /var/www/apache-lab/public>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ index.php [END]
</Directory>

این بخش امشب فقط مطالعه است؛ تا PHP آماده نشده، آن را روی سایت ثابت اعمال نکن. در context پوشه، الگوی RewriteRule slash ابتدایی ندارد. شرط‌های !-f و !-d فایل و پوشهٔ واقعی را از بازنویسی جدا می‌کنند.

چرا AllowOverride مهم است؟#

.htaccess پیکربندی درون پوشه است. وقتی مدیریت config سرور در اختیار ماست، قواعد را در Directory میزبان نگه می‌داریم و AllowOverride None می‌گذاریم. اگر نرم‌افزار واقعاً به تغییر .htaccess نیاز دارد، فقط directiveهای لازم را با AllowOverrideList مجاز کن؛ All انتخاب خودکار نیست.

آزمون و بازگشت: /old باید redirect شود ولی صفحهٔ اصلی نباید حلقه بسازد. قانون را بردار و انتظار داشته باش /old دوباره 404 شود. برای بررسی rewrite پیچیده می‌توانی موقتاً LogLevel warn rewrite:trace3 بگذاری و پس از یک درخواست به سطح عادی برگردانی.

منبع: Redirect در mod_alias ، mod_rewrite ، راهنمای .htaccess .