រុំព័ទ្ធប្រូកស៊ីតូចមួយអាចដំណើរការសម្រាប់ HTTPS ហើយបន្ទាប់មកជាប់គាំងនៅពេលប្រើឡើងវិញសម្រាប់ពិធីការដែលម៉ាស៊ីនមេរបស់វានិយាយមុន។ បន្ទាត់ដែលសង្ស័យជាញឹកញាប់គឺបន្ទាត់ដែលរង់ចាំឱ្យប៊ូហ្វ័រទទួល បញ្ចប់ ដោយ \r\n\r\n។

TCP ផ្តល់លំហូរដល់អតិថិជន។ ការហៅទទួលមួយអាចត្រឡប់មកវិញពាក់កណ្តាលបន្ទាត់ស្ថានភាព HTTP ការឆ្លើយតប CONNECT ពេញលេញ ឬការឆ្លើយតបនោះបន្តដោយទិន្នន័យផ្លូវរូងក្រោមដីភ្លាមៗ។ គ្មានការធានាថាការអានឈប់នៅចុងបញ្ចប់នៃបឋមកថាទេ។

ស្វែងរកព្រំដែននៅក្នុងប៊ូហ្វ័រ

សម្រាប់ការផ្លាស់ប្តូរ HTTP/1.1 CONNECT សូមប្រមូលបៃរហូតដល់ចំណុចបញ្ចប់បឋមកថាលេចឡើងនៅកន្លែងណាមួយក្នុងប៊ូហ្វ័រ។ បំបែកនៅកន្លែងដែលវាលេចឡើងដំបូង។ ញែកបន្ទាត់ស្ថានភាព និងបឋមកថាពីផ្នែកទីមួយ; រក្សាអ្វីៗទាំងអស់បន្ទាប់ពីព្រំដែនដោយឡែក។ អនុវត្តដែនកំណត់ទំហំបឋមកថា និងពេលវេលាកំណត់ពេលរង់ចាំ ហើយចាត់ទុកការអានសុីសុីសុីតទទេជាការតភ្ជាប់ដែលបានបិទ ជាជាងការអញ្ជើញផ្សេងទៀតឱ្យវិលជុំ។

ការឆ្លើយតប 2xx ជោគជ័យចុងក្រោយប្តូរការតភ្ជាប់ទៅរបៀបផ្លូវរូងក្រោមដីភ្លាមៗបន្ទាប់ពីបឋមកថាទាំងនោះ។ បៃដែលនៅពីក្រោយវាគឺជាបៃផ្លូវរូងក្រោមដីរួចហើយ។ កុំបោះបង់ពួកវា កុំ រង់ចាំតួការឆ្លើយតប CONNECT ហើយកុំបកស្រាយវាល Content-Length ថាជាការអនុញ្ញាតឱ្យប្រើផ្នែកមួយនៃពិធីការថ្មី។ ការឆ្លើយតបប្រភេទព័ត៌មាន ប្រសិនបើមាន ត្រូវដោះស្រាយមុនការឆ្លើយតបចុងក្រោយនោះ។

រុំព័ទ្ធត្រូវបញ្ជូនអ្វីដែលនៅសល់របស់វា

ការត្រឡប់តែសុីសុីសុីតខាងក្រោមនឹងបាត់បង់បៃណាមួយដែលឧបករណ៍ញែកការចាប់ដៃបានទាញចេញពីវារួចហើយ។ អ្នកអានបន្ទាប់ត្រូវការលំហូរប៊ូហ្វ័រដែលផ្តល់កន្ទុយដែលបានរក្សាទុកមុន បន្ទាប់មកបន្តការអានសុីសុីសុីត។ សម្រាប់ពិធីការដែលម៉ាស៊ីនមេនិយាយមុន ការបាត់បង់ការស្វាគមន៍ដំបូងនោះអាចធ្វើឱ្យភាគីទាំងពីររង់ចាំគ្មានទីបញ្ចប់។

ផ្ទុយទៅវិញ បៃពីការឆ្លើយតប CONNECT ដែលបរាជ័យមិនមែនជាការស្វាគមន៍ផ្លូវរូងក្រោមដីទេ។ 407 នៅតែជាកម្មសិទ្ធិរបស់ការផ្លាស់ប្តូរប្រូកស៊ី ហើយត្រូវការការដោះស្រាយការផ្ទៀងផ្ទាត់; ស្ថានភាពមិនជោគជ័យផ្សេងទៀតត្រូវការផ្លូវកំហុសសមស្រប។

រឿងនេះសំខាន់ជាពិសេសនៅពេលកែសម្រួលអតិថិជន FTP ឬ SSH តាមរយៈប្រូកស៊ី HTTP។ ប្រូកស៊ីក៏ត្រូវអនុញ្ញាតច្រកគោលដៅដែលបានស្នើផងដែរ ហើយ FTP អាចត្រូវការការតភ្ជាប់ទិន្នន័យបន្ថែម។ ការញែកបឋមកថាត្រឹមត្រូវដោះស្រាយការផ្ទេរលំហូរ; វាមិនអាចផ្តល់ការអនុញ្ញាត CONNECT ឬផ្តល់ឆានែលទីពីររបស់ FTP បានទេ។

អត្ថបទពាក់ព័ន្ធ