برنامهٔ ریشه همیشه زیر /service/ سالم کار نمی‌کند. امشب معنای slash در proxy_pass، هدرهای forwarded و اطلاعات بازگشتی را جدا بررسی می‌کنیم.

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

محیط: app و backend شب قبل؛ backup از APP_CONF. بعد از تمرین نگاشت ریشه بازیابی می‌شود.

URI مقصد#

location /service/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_http_version 1.1;
    include /etc/nginx/snippets/lab-proxy-headers.conf;
    proxy_set_header Connection "";
}

در این نمونه prefix /service/ با / جایگزین می‌شود؛ /service/readme.txt به /readme.txt backend می‌رود. اگر proxy_pass بدون URI انتهایی باشد، رفتار حفظ مسیر متفاوت است. متغیر در URL و rewrite نیز قواعد دیگری دارند؛ یک slash تصادفی تغییر معنایی است.

فایل readme.txt را در backend بساز و درخواست و لاگ آن را مقایسه کن. سرور سادهٔ Python cookie یا redirect برنامه‌ای ندارد؛ برای برنامهٔ واقعی endpointهایی با این پاسخ‌ها انتخاب کن و خروجی مستقیم و عمومی را با curl -D مقایسه کن.

proxy_redirect default;
proxy_cookie_path / /service/;

این‌ها در location مربوط به backend هستند و فقط بر هدرهای مربوط اثر دارند. cookie دارای Domain داخلی ممکن است به proxy_cookie_domain نیاز داشته باشد؛ cookie بدون Domain را بی‌دلیل تغییر نده. Secure، HttpOnly و SameSite باید با ورود و کاربرد برنامه سازگار باشند.

ارث‌بری هدر درخواست#

proxy_set_headerها فقط وقتی از والد به ارث می‌رسند که context فرزند تعریف اختصاصی نداشته باشد. در هر location دارای هدر ویژه، snippet پایه را نیز include کن؛ یک نام را با دو مقدار تعریف نکن. Host عمومی باید در برنامه اعتبارسنجی شود.

آزمون و بازگشت: CSS، redirect ورود، cookie Path و مسیر WebSocket را در برنامهٔ زیرمسیر بسنج. proxy_redirect بدنهٔ HTML و لینک‌های مطلق را کامل اصلاح نمی‌کند؛ برنامه باید base URL درست داشته باشد. config ریشهٔ سالم را برگردان.

منبع: URI، proxy_redirect و cookie .