នៅពេលដែលឯកសារដែលបានទាញយកចាប់ផ្តើមដោយបន្ទាត់ស្ថានភាព HTTP

ប្រសិនបើ PDF ឬសៀវភៅបញ្ជីដែលសន្មតថាជាឯកសារចាប់ផ្តើមដោយ HTTP/1.1 200 OK នោះកម្មវិធីទាញយកបានរក្សាទុកការឆ្លើយតបឆៅជំនួសឯកសារ។ ការឆ្លើយតបតាមគ្រោងការណ៍នេះមានតែបួនបៃនៃខ្លឹមសារ៖

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

ឯកសារគឺ DATA។ បន្ទាត់ស្ថានភាព ក្បាលរបាយការណ៍ សញ្ញាទំហំ និងរចនាសម្ព័ន្ធបញ្ចប់ជាកម្មសិទ្ធិរបស់ HTTP។ ការដកចំនួនបៃថេរគឺមិនមានសុវត្ថិភាពទេ ព្រោះប្រវែងក្បាលរបាយការណ៍ខុសគ្នា។ ការចម្លងអ្វីៗទាំងអស់បន្ទាប់ពីបន្ទាត់ទទេដំបូងនៅតែទុកការដាក់ស៊ុមបំណែក ហើយការឆ្លើយតបព័ត៌មានអាចមកមុនការឆ្លើយតបចុងក្រោយ។

សម្រាប់ការទាញយកធម្មតា សូមជំនួសការចម្លងពីរន្ធឆៅទៅឯកសារដោយចំណុចប្រទាក់តួការឆ្លើយតបរបស់កម្មវិធីភ្ញៀវ HTTP។ កំណត់រចនាសម្ព័ន្ធភ្នាក់ងាររបស់វា ផ្ទៀងផ្ទាត់ស្ថានភាពចុងក្រោយ ហើយបញ្ជូនតួទៅលទ្ធផលបណ្តោះអាសន្ន។ កម្មវិធីភ្ញៀវដោះស្រាយការដាក់ស៊ុមសារ៖ តួដែលកំណត់ដោយប្រវែង ដោយបំណែក និងដោយការតភ្ជាប់ត្រូវការការវិភាគផ្សេងៗគ្នា។

ការអ៊ិនកូដខ្លឹមសារគឺជាស្រទាប់មួយទៀត។ សម្រេចថាតើអ្នកត្រូវការបៃឯកសារដែលបានឌិកូដ ឬខ្លឹមសារឆៅដែលបានស្នើយ៉ាងច្បាស់ ដោយផ្អែកលើឥរិយាបថដែលបានចងក្រងរបស់កម្មវិធីភ្ញៀវ។ បៃដែលបានបង្ហាប់មិនមែនជាការខូចខាតភ្នាក់ងារដោយស្វ័យប្រវត្តិទេ។

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

HTTPS ត្រូវការច្រើនជាងការដកការឆ្លើយតប CONNECT ចេញ៖ បន្ទាប់ពីរៀបចំរូងក្រោមដីបានជោគជ័យ សូមបង្កើត TLS គោលដៅ បន្ទាប់មកវិភាគការឆ្លើយតប HTTP ខាងក្នុង។ បៃដែលបានអ៊ិនគ្រីបបន្ទាប់ពីក្បាលរបាយការណ៍របស់ភ្នាក់ងារមិនមែនជាឯកសារដែលអាចទាញយកបានទេ។

ទុកលទ្ធផលដែលបរាជ័យ ឬមិនពេញលេញក្រោមឈ្មោះបណ្តោះអាសន្ន។ ផ្សព្វផ្សាយវាតែបន្ទាប់ពីការផ្ទេរ និងការត្រួតពិនិត្យឯកសារជោគជ័យប៉ុណ្ណោះ។ ឯកសារដែលមិនទទេមិនបញ្ជាក់ពីការទាញយកពេញលេញទេ។