ការបកស្រាយស្ថានភាព និងកូដចេញរបស់ព្រុកស៊ី
រាយការណ៍ការប្រតិបត្តិពាក្យបញ្ជា លទ្ធផល HTTP និងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រ ដោយឡែកពីគ្នាក្នុងការពិនិត្យគេហទំព័រតាមរយៈព្រុកស៊ី។
សំបករុំមិនអាចបំប្លែងកូដចេញសូន្យរបស់កម្មវិធីទាញយកទៅជា “HTTP 200 OK” ដែលបានសង្កេតឃើញបានទេ។ កត់ត្រាអ្វីដែលស្រទាប់នីមួយៗបានរាយការណ៍ពិតប្រាកដ៖
| វាល | សំណួរដែលឆ្លើយ |
|---|---|
| ការចេញរបស់ឧបករណ៍ ឬកម្មវិធីបន្ថែម | តើការពិនិត្យបានដំណើរការ ហើយរាយការណ៍ប្រភេទបរាជ័យណា? |
| ការចរចាព្រុកស៊ី | តើការបញ្ជូនបន្ត ឬផ្លូវរូងដែលបានស្នើត្រូវបានអនុញ្ញាត? |
| ស្ថានភាពប្រភព និងមាតិកាដែលរំពឹង | តើកម្មវិធីបានត្រឡប់លទ្ធផលដែលចង់បាន? |
| ការផ្ទៀងផ្ទាត់ TLS | តើការត្រួតពិនិត្យអត្តសញ្ញាណដែលបានកំណត់បានជោគជ័យ? |
ជាធម្មតា curl អាចត្រឡប់សូន្យបន្ទាប់ពីការឆ្លើយតបកំហុស HTTP។ ជម្រើស fail របស់វាផ្លាស់ប្ដូរឥរិយាបថចេញ ប៉ុន្តែការចេញដោយបរាជ័យនៅតែមិនកំណត់ស្ថានភាពដោយឡែក។ តម្លៃចេញរបស់ Wget ក៏ជាប្រភេទដែរ៖ ការបរាជ័យផ្ទៀងផ្ទាត់មិនមែនជាតម្លៃពិសេសសម្រាប់ HTTP 401 ទេ ហើយប្រភេទកំហុសម៉ាស៊ីនមេមិនកំណត់រាល់ការឆ្លើយតបនៅក្នុងវាទេ។ ការពិនិត្យដែលរំពឹង 401 ត្រូវតែសង្កេតឃើញការឆ្លើយតបនោះ។
រក្សាចំណុចបញ្ចប់ព្រុកស៊ី និងឈ្មោះគេហទំព័រដោយឡែកពីគ្នា។ ដៃគូ TCP នៃការពិនិត្យព្រុកស៊ី HTTP គឺព្រុកស៊ី; CONNECT ដាក់ឈ្មោះគោលដៅ ដែលសម័យ TLS របស់វាបន្ទាប់មកដំណើរការនៅក្នុងផ្លូវរូង។ ចំពោះព្រុកស៊ី HTTPS ការជឿទុកចិត្តលើព្រុកស៊ីខាងក្រៅគឺ ការត្រួតពិនិត្យវិញ្ញាបនបត្រមួយទៀត។
ពិនិត្យការធានារបស់កម្មវិធីបន្ថែមមុនពេលចាត់ទុកសញ្ញា SSL ជាការផ្ទៀងផ្ទាត់។ Monitoring Plugins ដក check_http ចេញ ដើម្បីជំនួសដោយ check_curl។ ឯកសារ check_http ព្រមានថាការជ្រើស SSL តែម្នាក់ឯងមិនផ្ទៀងផ្ទាត់ឈ្មោះម៉ាស៊ីន ឬការជឿទុកចិត្តលើអ្នកចេញវិញ្ញាបនបត្រទេ; ជម្រើស verify-peer ដែលបានចងក្រងក្នុងឯកសាររបស់ check_curl រួមបញ្ចូលការផ្ទៀងផ្ទាត់នោះ។
ប្រើផ្លូវដែលបានផ្ទៀងផ្ទាត់ដែលបានបម្រុងទុកផងដែរ។ ការស្ទង់ច្រកអាចនៅបៃតង ខណៈគណនីប្រតិបត្តិទទួលបាន 407។ ប្រគល់អាថ៌កំបាំងរបស់វាតាមយន្តការសមស្របនៃការដាក់ពង្រាយ ហើយរាយការណ៍ដំណាក់កាលដែលបរាជ័យពិតប្រាកដ៖ ផ្លូវរូងដែលត្រូវបានបដិសេធត្រូវការការជួសជុលខុសពីស្ថានភាពគេហទំព័រដែលមិនបានរំពឹង។