د پراکسي تصدیق بیا هڅې او د اپلوډ نه تکراریدونکي بدنونه
پوه شئ چې ولې د تصدیق بیا هڅې کولی شي یو ځل اپلوډ بهیر څرګند کړي، او په قصدي ډول محدود بفر یا د تکرار وړ منځپانګه غوره کړئ.
GET کولی شي د پراکسي له لارې تصدیق شي، خو POST یا PUT د نه تکراریدونکي بدن یا د بیرته تاوولو د تېروتنې سره ناکام کیږي. حساب ممکن سم وي: د تصدیق تبادله ممکن وروسته له دې چې مراجع اپلوډ کارولی وي یو بل غوښتنه وغواړي.
| د بدن سرچینه | د تکرار انتخاب |
|---|---|
| کوچنی محدود بدن | محدود بفر کولی شي د هغې بایټ وساتي. |
| د لټون وړ فایل | د مراجع لخوا ملاتړ شوی د بیرته تاوولو انٹرفیس کولی شي هغه د تکرار وړ کړي. |
| جنراتور، پایپ یا ژوندی تولیدوونکی | یو ځل سرچینه ممکن بل ډیزاین ته اړتیا ولري. |
libcurl د څو پړاوه تصدیق په ګډون کارونو لپاره د لټون کال بیکونه مستند کوي. Jersey د کنیکټر چلند تابع بفر شوي او ویشل شوي entity پروسسینګ حالتونه وړاندې کوي. یوه Jersey 2 Apache کنیکټر بېلګه بفر شوې ترتیبات ښیي. هیڅ یو یې هم په حافظه کې نامحدود اپلوډونه مناسب نه کوي.
هغه طریقه او د بدن سرچینه چې ناکام کیږي بیا تولید کړئ. چمتوونکی GET د تکرار لپاره اپلوډ نلري، او دا نه ثابتیږي چې وروستی اپلوډ د هغې اړیکه یا تصدیق حالت شریکوي. نوی هدف، د مراجع شی یا د اړیکې پالیسي کولی شي دا بدل کړي. د فایل پر بنسټ بدن او ژوندی جریان هم توپیر لري حتی کله چې د دوی نمونه متن یو شان وي.
که تاسو بفر کوئ، د هغې اندازه حد، د ذخیره کولو ځای او عمر تعریف کړئ. یو وخت اپلوډونه لګښت څو چنده کوي، او حساس معلومات چېرې چې بفر ساتل کیږي هلته پاتې کیږي.
پیژندل شوي مطابق پراکسي ته مخکې تصدیق کولی شي یوه لومړنۍ ننګونه مخنیوی کړي. خو دا نشي کولی هر وروستی تصدیق پړاو، بیا لارښوونه یا بند اړیکه خارج کړي چې ممکن بله هڅه وغواړي.
د پراکسي ځواب، د بدن د کارولو ټکی او د تکرار تېروتنه یو ځای وساتئ. بیا د پروتوکول تکرار له نامعلوم اپلیکیشن پایلې څخه جلا کړئ: ممکن سپارل مخکې له دې چې ځواب یې ورک شي پروسس شوی وي. د بیا لیږلو دمخه د هدف idempotency قواعد تعقیب کړئ.