Python HTTP پراکسی کے POST باڈی rfile میں بفر کیے جا سکتے ہیں
Python HTTP پراکسی کی درخواست کو handler کے بفر شدہ ان پٹ سے پڑھیں، اُن بائٹس کا انتظار کرنے کے بجائے جو پہلے ہی socket بفر سے نکل چکے ہیں۔
فارورڈ پراکسی درخواست کی سطر اور ہیڈر پڑھتی ہے، اُنہیں آگے بھیجتی ہے، پھر select میں POST باڈی کا انتظار کرتی ہے۔ کلائنٹ اُسے پہلے ہی بھیج چکا ہے۔ دونوں فریق ایک دوسرے کا انتظار کرتے دکھائی دیتے ہیں۔
Python کے BaseHTTPRequestHandler میں ہیڈر پڑھنا rfile سے گزرتا ہے، جو ایک بفر شدہ ان پٹ اسٹریم ہے۔ وہ اسٹریم آگے پڑھ سکتا ہے اور باڈی سے متعلق بائٹس رکھ سکتا ہے۔ بنیادی socket پر انتظار صرف یہ پوچھتا ہے کہ اُس کا فائل ڈسکرپٹر تیار ہے یا نہیں؛ یہ نہیں پوچھتا کہ Python اسٹریم میں پہلے ہی قابلِ استعمال ڈیٹا موجود ہے یا نہیں۔
اُس بفر کی پیروی کریں جس نے ہیڈر پڑھے
باڈی بھی self.rfile کے ذریعے پڑھیں۔ بفر شدہ اسٹریم سے ہیڈر تجزیہ کرنے کے بعد self.connection.recv پر نہ جائیں۔ ورنہ کوڈ اُس اسٹریم میں موجود بائٹس کو چھوڑ کر ایسے ڈیٹا کا انتظار کر سکتا ہے جو دوبارہ کبھی نہیں بھیجا جائے گا۔
rfile کو خود select کو دینے سے select اُس کا Python بفر نہیں دیکھتا۔ تیاری کا API آبجیکٹ کے فائل ڈسکرپٹر کے ذریعے کام کرتا ہے۔
ایک درست Content-Length والی اور Transfer-Encoding کے بغیر درخواست کے لیے، اعلان کردہ بائٹس کی تعداد بالکل استعمال کریں، ان پٹ کے قبل از وقت خاتمے اور اپنی جسامت و وقت کی حدوں کو سنبھالیں۔ EOF تک نہ پڑھیں: مستقل کنکشن استعمال کرنے والا کلائنٹ درخواست ختم ہونے کے بعد بھی کنکشن کھلا رکھ سکتا ہے۔
فریمنگ کو پراکسی کا واضح حصہ بنائیں
چنک شدہ درخواست باڈی کے لیے چنک شدہ فریمنگ کی معاونت درکار ہے۔ غیر موجود Content-Length ڈھونڈ کر اُنہیں پڑھا نہیں جا سکتا۔ مبہم لمبائی میٹاڈیٹا کے لیے متعین مسترد راستہ چاہیے، بجائے اُس ہیڈر کے انتخاب کے جو سہولت بخش لگے۔
بلاکنگ handler محدود پڑھائی کے ساتھ اپنا اسٹریم انٹرفیس استعمال کر سکتا ہے۔ ایونٹ سے چلنے والی پراکسی کو ایسا بفر ماڈل چاہیے جو پارسر کی آگے پڑھائی کو تیاری کے انتظام کے ساتھ یکجا کرے۔ ٹائم آؤٹ بدلنے سے ایک ہی socket کے دو خودمختار صارفین نہیں مل سکیں گے۔
یہ تشخیص خاص طور پر اِس بارے میں ہے کہ آنے والے بائٹس کہاں رکھے جاتے ہیں۔ پراکسی درست باڈی استعمال کرنے کے بعد بھی اُس باڈی کو مستقل HTTP فریمنگ کے ساتھ آگے بھیجے گی۔ معیاری http.server handler طریقہ کار سمجھنے کے لیے مفید جگہ ہے، مگر یہ پیداواری فارورڈ پراکسی کی تنفیذ نہیں ہے۔