یک قاعده http://reports.example:80/ را از طریق پروکسی می‌فرستد اما http://reports.example/ را مستقیم عبور می‌دهد. این دو نشانی همان نقطه پایانی معمولی HTTP را توصیف می‌کنند. ناسازگاری معمولاً از مقایسه تحت‌اللفظی پورت‌های تجزیه‌شده ناشی می‌شود.

URI.getPort() هنگامی که پورتی در URI نیامده باشد -1 برمی‌گرداند. مقدار پیش‌فرض طرح را جایگزین نمی‌کند. سیاست مسیریابی که مقدار را با 80 مقایسه کند، نشانی دوم را از دست می‌دهد.

String scheme = uri.getScheme();
int port = uri.getPort();
if (port == -1) {
    if ("http".equalsIgnoreCase(scheme)) port = 80;
    else if ("https".equalsIgnoreCase(scheme)) port = 443;
}

همان یکسان‌سازی را بر دو طرف مقایسه اعمال کنید. اصلاح تنها URI درخواست، مقصد پیکربندی‌شده با پورت حذف‌شده را بی‌تطابق باقی می‌گذارد. میزبان، پورت مؤثر و طرح موردنظر را مقایسه کنید؛ مقصدهای بدشکل یا بدون میزبان را از طریق مسیر خطای تعریف‌شده رد کنید.

هر فراخوانی را به تصمیم HTTP تبدیل نکنید

انتخابگر پیش‌فرض ممکن است برای اتصال‌های سوکت خام نیز با طرح socket پرسیده شود. صرف تطابق میزبان و پورت نباید باعث شود آن فراخوانی یک پروکسی HTTP که برای درخواست‌های URL در نظر گرفته شده است برگرداند. طرح‌های پشتیبانی‌نشده را به انتخابگر قبلی واگذار کنید و رفتار مناسب آن را حفظ کنید.

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

هنگام عیب‌یابی ناسازگاری، طرح، میزبان، پورت اصلی و پورت مؤثر را ثبت کنید. به یک عدد مشاهده‌شده یا ترتیب خاص فراخوانی‌ها در پیاده‌سازی‌های JDK تکیه نکنید. سیاست باید برای هر URI ارائه‌شده تصمیم درست بگیرد.

مقالات مرتبط