גופי POST בפרוקסי HTTP של Python יכולים להיחסם ב-rfile

פרוקסי ה-forward קורא את שורת הבקשה ואת הכותרות, מעביר אותן הלאה ואז ממתין ב-select לגוף POST. הלקוח כבר שלח אותו. נראה ששני הצדדים ממתינים זה לזה.

עם BaseHTTPRequestHandler של Python, קריאת הכותרות עוברת דרך rfile, זרם קלט מאוחסן. הזרם הזה יכול לקרוא קדימה ולהחזיק בייטים ששייכים לגוף. המתנה על ה-socket הבסיסי שואלת רק אם מתאר הקובץ שלו מוכן; היא לא שואלת אם זרם ה-Python כבר מכיל נתונים שמישים.

עקבו אחרי המאגר שקרא את הכותרות

קראו את הגוף גם דרך self.rfile. אל תעברו ל-self.connection.recv לאחר שפרסתם את הכותרות עם הזרם המאוחסן. אחרת הקוד עלול לדלג על בייטים שהזרם כבר מחזיק ולהמתין לנתונים שלעולם לא יישלחו שוב.

העברת rfile עצמו ל-select לא גורמת ל-select לבדוק את מאגר ה-Python שלו. ממשק המוכנות פועל דרך מתאר הקובץ של האובייקט.

עבור בקשה עם Content-Length תקף אחד וללא Transfer-Encoding, צרכו בדיוק את מספר הבייטים המוצהר, תוך טיפול בסיום מוקדם של הקלט ובמגבלות הגודל והזמן שלכם. אל תקראו עד EOF: לקוח שמשתמש בחיבור מתמשך עשוי להשאיר את החיבור פתוח לאחר סיום הבקשה.

הפכו את המסגור לחלק מפורש מהפרוקסי

גופי בקשה ב-chunked זקוקים לתמיכת מסגור chunked. אי אפשר לקרוא אותם בחיפוש אחר Content-Length חסר. מטא-נתוני אורך דו-משמעיים זקוקים לנתיב דחייה מוגדר, במקום לבחור את הכותרת שנראית נוחה.

מטפל חוסם יכול להמשיך להשתמש בממשק הזרם שלו עם קריאות מוגבלות. פרוקסי מונחה אירועים זקוק למודל מאגר שמשלב קריאה מוקדמת של המנתח עם טיפול במוכנות. שינוי פסק זמן לא יפייס שני צרכנים בלתי תלויים של אותו socket.

האבחון הזה ספציפי למקום שבו מוחזקים הבייטים הנכנסים. לאחר שהפרוקסי צרך את הגוף הנכון, הוא עדיין צריך להעביר אותו עם מסגור HTTP עקבי. המטפל הסטנדרטי http.server הוא מקום שימושי להבנת המנגנון, אך אינו מימוש פרוקסי forward לייצור.