آیا بازنویسی‌کننده URL در Squid می‌تواند بدنه پاسخ‌ها را تغییر دهد؟
هنگام گسترش یک پروکسی پیشرو، انتخاب URL درخواست را از سازگارسازی پاسخ و رمزگشایی TLS جدا نگه دارید.
url_rewrite_program روی تصمیم‌های URL درخواست کار می‌کند. اطلاعات درخواست را دریافت می‌کند و از طریق پروتکل کمکی Squid پاسخ می‌دهد؛ فایلی دانلودشده دریافت نمی‌کند تا آن را ویرایش و بازگرداند.
| عملیات موردنظر | مرز مربوط |
|---|---|
| تغییر مسیر مرورگر یا انتخاب URL درخواست دیگر | نقش کمکی بازنویسی URL در مرحله درخواست |
| تغییر بدنه پاسخ HTTP قابل مشاهده | ابزاری برای سازگارسازی پاسخ، مانند تغییر پاسخ ICAP پیکربندی‌شده |
| خواندن HTTP درون CONNECT معمولی | ابتدا باید TLS مقصد در چیدمان استقرار مناسب پایان یابد |
| رمزگشایی فایلی که یک برنامه آن را رمز کرده است | قالب، الگوریتم و کلید فایل، مستقل از شیوه انتقال آن |
دو سطر آخر به‌آسانی با هم اشتباه می‌شوند. فایل معمولی که روی HTTPS منتقل می‌شود با TLS محافظت می‌شود. فایلی که یک برنامه رمز کرده است می‌تواند حتی پس از پایان HTTPS رمزشده بماند. انتخاب یک رابط سازگارسازی نه کلید برنامه را فراهم می‌کند و نه الگوریتم رمزگشایی آن را.
CONNECT معمولی بایت‌های رمزشده تونل را عبور می‌دهد. کمکی URL پاسخ درونی را آشکار نمی‌کند؛ طرحی که به بازرسی نیاز دارد باید مشخص کند که آیا این ترافیک در استقرار قابل رمزگشایی است و باید رمزگشایی شود یا نه.
جایی که Squid می‌تواند پیام HTTP را بازرسی کند، سرویس تغییر پاسخ همچنان مالک کدگذاری‌های محتوا، طول‌های تغییر‌یافته و رفتار در برابر خطاست. رابط را پس از تعریف تبدیل انتخاب کنید، نه اینکه یک نمونه کارآمد بازنویسی URL را به مرحله پردازشی گسترش دهید که هرگز آن را دریافت نمی‌کند.