តួ POST របស់ប្រូកស៊ី HTTP Python អាចត្រូវបានរក្សាទុកក្នុង rfile

ប្រូកស៊ីបញ្ជូនបន្តអានបន្ទាត់សំណើ និងក្បាល បញ្ជូនពួកវា បន្ទាប់មករង់ចាំក្នុង select សម្រាប់តួ POST។ អតិថិជនបានផ្ញើវារួចហើយ។ ភាគីទាំងពីរហាក់ដូចជារង់ចាំគ្នាទៅវិញទៅមក។

ជាមួយ BaseHTTPRequestHandler របស់ Python ការអានក្បាលឆ្លងកាត់ rfile ដែលជាស្ទ្រីមបញ្ចូលដែលបានរក្សាទុក។ ស្ទ្រីមនោះអាចអានទៅមុខ និងរក្សាបៃដែលជាកម្មសិទ្ធិរបស់តួ។ ការរង់ចាំលើ socket ខាងក្រោមគ្រាន់តែសួរថាតើ file descriptor របស់វារួចរាល់ឬអត់; វាមិនសួរថាតើស្ទ្រីម Python មានទិន្នន័យដែលអាចប្រើបានរួចហើយឬអត់។

ដើរតាម buffer ដែលបានអានក្បាល

អានតួតាមរយៈ self.rfile ផងដែរ។ កុំប្តូរទៅ self.connection.recv បន្ទាប់ពីញែកក្បាលដោយស្ទ្រីមដែលបានរក្សាទុក។ បើមិនដូច្នេះទេ កូដអាចរំលងបៃដែលស្ទ្រីមនោះកំពុងរក្សា ហើយរង់ចាំទិន្នន័យដែលនឹងមិនត្រូវបានផ្ញើម្តងទៀត។

ការបញ្ជូន rfile ខ្លួនវាទៅ select មិនធ្វើឱ្យ select ពិនិត្យ buffer Python របស់វាទេ។ API ភាពរួចរាល់ដំណើរការតាមរយៈ file descriptor របស់វត្ថុ។

សម្រាប់សំណើដែលមាន Content-Length ត្រឹមត្រូវមួយ និងគ្មាន Transfer-Encoding សូមប្រើប្រាស់ចំនួនបៃដែលបានប្រកាសយ៉ាងជាក់លាក់ ដោយដោះស្រាយការបញ្ចប់ធាតុបញ្ចូលមុនពេល និងដែនកំណត់ទំហំ និងពេលវេលារបស់អ្នក។ កុំអានរហូតដល់ EOF: អតិថិជនដែលប្រើការតភ្ជាប់បន្តអាចទុកការតភ្ជាប់បើកបន្ទាប់ពីបញ្ចប់សំណើ។

ធ្វើឱ្យការដាក់ស៊ុមជាផ្នែកច្បាស់លាស់របស់ប្រូកស៊ី

តួសំណើ chunked ត្រូវការការគាំទ្រការដាក់ស៊ុម chunked។ ពួកវាមិនអាចអានដោយរក Content-Length ដែលអវត្តមានបានទេ។ ទិន្នន័យប្រវែងមិនច្បាស់ត្រូវការផ្លូវបដិសេធដែលកំណត់ ជំនួសឱ្យការជ្រើសរើសក្បាលដែលហាក់ដូចជាងាយស្រួល។

handler បាំងអាចបន្តប្រើចំណុចប្រទាក់ស្ទ្រីមរបស់វាជាមួយការអានមានកំណត់។ ប្រូកស៊ីដែលជំរុញដោយព្រឹត្តិការណ៍ត្រូវការគំរូ buffer ដែលរួមបញ្ចូលការអានទៅមុខរបស់ parser ជាមួយការគ្រប់គ្រងភាពរួចរាល់។ ការផ្លាស់ប្តូរ timeout នឹងមិនផ្សះផ្សាអ្នកប្រើឯករាជ្យពីរនៃ socket តែមួយ។

ការធ្វើរោគវិនិច្ឆ័យនេះគឺជាក់លាក់ចំពោះកន្លែងដែលបៃចូលត្រូវបានរក្សា។ នៅពេលប្រូកស៊ីបានប្រើប្រាស់តួត្រឹមត្រូវហើយ វានៅតែត្រូវបញ្ជូនតួនោះជាមួយការដាក់ស៊ុម HTTP ស្របគ្នា។ handler http.server ស្តង់ដារគឺជាកន្លែងមានប្រយោជន៍ដើម្បីយល់ពីយន្តការ ប៉ុន្តែវាមិនមែនជាការអនុវត្តប្រូកស៊ីបញ្ជូនបន្តសម្រាប់ផលិតកម្មទេ។