សំបករុំមិនអាចបំប្លែងកូដចេញសូន្យរបស់កម្មវិធីទាញយកទៅជា “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។ ប្រគល់អាថ៌កំបាំងរបស់វាតាមយន្តការសមស្របនៃការដាក់ពង្រាយ ហើយរាយការណ៍ដំណាក់កាលដែលបរាជ័យពិតប្រាកដ៖ ផ្លូវរូងដែលត្រូវបានបដិសេធត្រូវការការជួសជុលខុសពីស្ថានភាពគេហទំព័រដែលមិនបានរំពឹង។

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