ការតភ្ជាប់បើក។ ក្បាលសំណើចេញទៅ។ ហាក់ដូចជាឯកសារមិនធ្វើចលនា។ ការពន្យល់មួយគឺថា អតិថិជនកំពុងរង់ចាំការឆ្លើយតបចំពោះ Expect: 100-continue មុនពេលផ្ញើតួរបស់ខ្លួន។

យន្តការនេះអនុញ្ញាតឱ្យអ្នកទទួលបដិសេធសំណើដោយផ្អែកលើក្បាលរបស់វា មុនពេលការផ្ទុកឡើងដែលអាចធំត្រូវបានផ្ញើ។ លំដាប់ជោគជ័យធម្មតាគឺ៖

request headers → 100 Continue → request body → final response

100 គឺជាព័ត៌មាន៖ វាអនុញ្ញាតឱ្យអតិថិជនបន្ត ប៉ុន្តែមិនមានន័យថាឯកសារត្រូវបានរក្សាទុក ឬប្រតិបត្តិការកម្មវិធីបានជោគជ័យទេ។ Git push ដែលត្រឡប់ HTTP 417 គឺជាករណីជាក់ស្តែងមួយនៃការរំពឹងដែលបរាជ័យ។

រកឱ្យឃើញថាអតិថិជនទទួលបានការឆ្លើយតបណា

ការសង្កេតអត្ថន័យដែលត្រូវស៊ើបអង្កេត
100 Continueអតិថិជនអាចបន្តជាមួយតួ
ការបដិសេធចុងក្រោយមុនតួប្រតិបត្តិការត្រូវបានបដិសេធនៅដំណាក់កាលក្បាល
គ្មានការឆ្លើយតបបណ្តោះអាសន្នដែលរំពឹងទុកគោលនយោបាយរង់ចាំរបស់អតិថិជន និងការដោះស្រាយលើផ្លូវនោះ

curl ផ្តល់ការកំណត់រង់ចាំដោយឡែកសម្រាប់ expect-continue។ ប្រសិនបើការរង់ចាំ libcurl នោះផុតកំណត់ដោយគ្មានការឆ្លើយតបដែលរំពឹងទុក វានៅតែផ្ញើតួ។ ការផុតកំណត់មិនមែនជាការបរាជ័យស្វ័យប្រវត្តិនៃការផ្ទេរទាំងមូលទេ។ ការកំណត់នេះដាច់ដោយឡែកពីពេលដែលអនុញ្ញាតសម្រាប់ការផ្ទេរពេញលេញ។ ការបង្កើនចុងក្រោយអាចទុកការផ្អាកដំបូងដូចគ្នាដោយគ្មានការពន្យល់។

ក៏ត្រូវកំណត់ផងដែរថាតើការសន្ទនា HTTP ណាដែលផ្ទុក Expect។ ជាមួយ CONNECT ធម្មតាទៅគោលដៅ HTTPS ការផ្លាស់ប្តូរការផ្ទុកឡើងរបស់គេហទំព័រស្ថិតនៅក្នុង TLS។ ប្រូកស៊ីបញ្ជូនបន្តមិនគ្រាន់តែពិនិត្យក្បាលការរំពឹងខាងក្នុងរបស់វាទេ។ ផ្លូវស្ទាក់ចាប់ ឬបញ្ជូនជាអត្ថបទច្បាស់គឺខុសគ្នា។

ការដកការរំពឹងចេញអាចជាជម្រើសភាពឆបគ្នាដោយចេតនា ប៉ុន្តែវាមានន័យថាអតិថិជនអាចចាប់ផ្តើមផ្ញើតួធំ មុនពេលដឹងពីការបដិសេធដំបូង។ ប្រៀបធៀបឥរិយាបថនោះជាមួយតម្រូវការពិត។ សូមមិនត្រូវពណ៌នាដំណោះស្រាយប្រវត្តិសាស្ត្រសម្រាប់ប្រូកស៊ីចាស់ ជាការណែនាំសកលឱ្យដកក្បាលចេញពីរាល់ការផ្ទុកឡើង។

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