در Squid گزینه‌ای به نام retry_on_error وجود دارد، اما نامش از تفسیر مفید آن گسترده‌تر است. به این معنا نیست که هر درخواست ناموفق تا زمانی که صفحه کار کند بی‌پایان تکرار می‌شود.

در نسخه‌هایی که این دستور را پشتیبانی می‌کنند، به‌طور پیش‌فرض خاموش است. فهرست مستند تکرار شامل 403، 500، 501، 502، 503 و 504 است و درخواست را از طریق مقصد کاری دیگری امتحان می‌کند. این موضوع به‌ویژه در سلسله‌مراتبی با مسیرهای ارسال جایگزین اهمیت دارد. این فقط تلاش مجدد زمان‌بندی‌شدهٔ همان سوکت به همان سرور نیست.

نخست خطا را نام ببرید

رد شدن هنگام اتصال به پروکسی، شکست احراز هویت پروکسی، خطای HTTP از مبدأ و پاسخی که پس از آغاز تحویل قطع شده است، فرصت تکرار یکسانی ارائه نمی‌دهند. انتظار نداشته باشید یک تنظیم هر چهار مورد را یکسان اداره کند.

برای خروج خصوصی، همچنین تصمیم بگیرید که آیا مسیر جایگزین پذیرفتنی است. والد دیگر ممکن است نشانی مبدأ عمومی، سیاست احراز هویت یا موقعیت شبکهٔ متفاوتی داشته باشد. موفقیت از طریق آن جایگزین ممکن است دلیل انتخاب والد نخست را نقض کند.

عملیات برنامه نگرانی دیگری می‌آورد: تکرار یک درخواست می‌تواند اثر آن را تکرار کند. کلاینت و سرور به معناشناسی تکرار مناسب نیاز دارند، به‌ویژه برای عملیاتی که داده ایجاد یا تغییر می‌دهند. تنظیم پروکسی جایگزین مدیریت نتیجه‌های نامعلوم در سطح برنامه نیست.

دستور را برای نسخهٔ دقیق خود بخوانید؛ مرجع دسترس‌پذیری و رفتار پیش‌فرض را فهرست می‌کند. همچنین مهلت‌های درخواست و کل انتظار قابل‌مشاهدهٔ کاربر را در نظر داشته باشید. یک تلاش ارسال اضافی می‌تواند زمان باقی‌مانده را مصرف کند بی‌آنکه نتیجهٔ بهتری بدهد.

هنگام بررسی خطاهای گاه‌به‌گاه، وضعیت، والد یا مقصد انتخاب‌شده و ترتیب تلاش‌ها را ثبت کنید. در غیر این صورت، تکرارها می‌توانند یک مشکل مسیریابی تکرارشونده را شبیه وب‌سایتی عموماً کند نشان دهند و مسیری را که واقعاً شکست خورده پنهان کنند.

مقالات مرتبط