تلاش‌های مجدد احراز هویت پروکسی و بدنه‌های آپلود غیرقابل تکرار
درک کنید چرا تلاش‌های مجدد احراز هویت می‌توانند جریان آپلود یک‌باره را آشکار کنند، و آگاهانه بافر محدود یا محتوای قابل تکرار را انتخاب کنید.
یک GET می‌تواند از طریق پروکسی احراز هویت شود، در حالی که POST یا PUT با خطای بدنه غیرقابل تکرار یا خطای عقب‌گرد شکست می‌خورد. ممکن است حساب درست باشد: تبادل احراز هویت می‌تواند پس از مصرف آپلود توسط کلاینت، درخواست دیگری بخواهد.
| منبع بدنه | انتخاب تکرار |
|---|---|
| بدنه کوچک محدود | بافر محدود می‌تواند بایت‌های آن را نگه دارد. |
| فایل قابل جست‌وجو | رابط عقب‌گردی که کلاینت پشتیبانی می‌کند می‌تواند آن را قابل تکرار کند. |
| مولد، لوله یا تولیدکننده زنده | منبع یک‌باره ممکن است طراحی دیگری لازم داشته باشد. |
libcurl توابع برگشتی جست‌وجو را برای کاربردهایی از جمله احراز هویت چندمرحله‌ای مستند می‌کند. Jersey حالت‌های پردازش موجودیت بافرشده و تکه‌تکه را بسته به رفتار اتصال‌دهنده ارائه می‌دهد. یک نمونه اتصال‌دهنده Jersey 2 Apache تنظیم بافرشده را نشان می‌دهد. هیچ‌کدام آپلودهای نامحدود در حافظه را مناسب نمی‌کنند.
روش و منبع بدنه‌ای را که شکست می‌خورند بازتولید کنید. یک GET آماده‌سازی هیچ آپلودی برای تکرار ندارد و ثابت نمی‌کند که آپلود بعدی اتصال یا وضعیت احراز هویت آن را به اشتراک می‌گذارد. مقصد، شیء کلاینت یا سیاست اتصال جدید می‌تواند آن را تغییر دهد. بدنه مبتنی بر فایل و جریان زنده نیز حتی وقتی متن نمونه‌شان یکسان است متفاوت‌اند.
اگر بافر می‌کنید، محدودیت اندازه، محل ذخیره‌سازی و عمر آن را تعریف کنید. آپلودهای هم‌زمان هزینه را چند برابر می‌کنند و داده‌های حساس هر جا که بافر نگه داشته شود باقی می‌مانند.
احراز هویت پیش‌دستانه به یک پروکسی سازگار شناخته‌شده می‌تواند از یک چالش اولیه جلوگیری کند. اما نمی‌تواند هر دور احراز هویت، تغییر مسیر یا اتصال بسته بعدی را که ممکن است تلاش دیگری بخواهد کنار بگذارد.
پاسخ پروکسی، نقطه مصرف بدنه و خطای تکرار را کنار هم نگه دارید. سپس تکرار پروتکل را از نتیجه نامطمئن برنامه تشخیص دهید: ممکن است یک ارسال پیش از از دست رفتن پاسخش پردازش شده باشد. پیش از ارسال دوباره، قواعد idempotency مقصد را رعایت کنید.