ការអានការផ្ទុកឡើងជាបំណែកៗមិនត្រូវការ chunked HTTP ទេ

ទេ។ អតិថិជនអាចអានឯកសារធំក្នុងបឺហ្វឺតូចៗ ហើយផ្ញើវាជាមួយ Content-Length ដែលដឹង។ ការអានមានដែនកំណត់គ្រប់គ្រងការប្រើប្រាស់អង្គចងចាំ។ ការធ្វើស៊ុម HTTP ប្រាប់អ្នកទទួលថាតើតួសំណើបញ្ចប់នៅឯណា។

ឯកសារនឹងនៅក្រៀមលក្ខណៈដែលបណ្ណាល័យ HTTP ដឹងប្រវែងបៃរបស់វាខុសពីកម្មវិធីបង្កើតដែលបង្កើតបរិមាណទិន្នន័យមិនដឹង។ ប្រើចំណុចប្រទាក់តួដែលបណ្ណាល័យគាំទ្រសម្រាប់ប្រភពទាំងពីរ។ អ្នកមិនចាំបាច់ប្រមូលឯកសារទាំងមូលទៅជាខ្សែអក្សរដើម្បីផ្ដល់ប្រវែងទេ។

សម្រាប់ HTTP/1.1 សូមពិនិត្យការធ្វើស៊ុមដែលបានផ្ញើពិតប្រាកដ៖ Content-Length ឬការសរសេរកូដផ្ទេរ chunked តាមច្បាប់របស់ពិធីការ។ ការសរសេរកូដ chunked បន្ថែមសញ្ញារង្វាស់នៅខាងក្រៅមាតិកាឯកសារ។ កុំបញ្ចូលវាលធ្វើស៊ុមដែលផ្ទុយគ្នា និងកុំទាយប្រវែងដើម្បីបញ្ចុះបញ្ចូលភ្នាក់ងារឆ្លងកាត់ឲ្យទទួលយកការផ្ទុកឡើង។

ប្រសិនបើការផ្ទុកឡើងតាមភ្នាក់ងារឆ្លងកាត់បរាជ័យ សូមកត់ត្រាកំណែ HTTP ប្រភពតួ និងការបដិសេធដំបូង។ ការឆ្លើយតប 411 បង្ហាញការស៊ើបអង្កេតផ្សេងពីការតភ្ជាប់ដែលបិទពាក់កណ្តាលតួ។ ប្រសិនបើជំនួសមកវិញការព្យាយាមផ្ទៀងផ្ទាត់ឡើងវិញបរាជ័យ សូមពិនិត្យ ថាតើតួនៃការផ្ទុកឡើងអាចលេងឡើងវិញបានឬអត់។ ការផ្លាស់ប្តូរទំហំបឺហ្វឺរអានរបស់កម្មវិធីអាចទុកការធ្វើស៊ុមសំណើដូចដើម។

ផ្លូវមានសារៈសំខាន់ចំពោះការសង្កេតនោះ។ ការផ្ទេរអត្ថបទច្បាស់លាស់បង្ហាញការធ្វើស៊ុម HTTP នៃការផ្ទុកឡើងដល់ភ្នាក់ងារឆ្លងកាត់។ HTTPS ពីចុងដល់ចុងធម្មតាដាក់វានៅក្នុងផ្លូវរូង។ HTTP/2 ប្រើការធ្វើស៊ុមផ្ទាល់ខ្លួន។ ដូច្នេះ ដែនកំណត់ប្រវត្តិសាស្ត្ររបស់ Squid ពន្យល់ការបរាជ័យចាស់ៗជាក់លាក់ មិនមែនជាច្បាប់ថាភ្នាក់ងារឆ្លងកាត់បច្ចុប្បន្នទាំងអស់បដិសេធការផ្ទុកឡើងជាស្ទ្រីមទេ។