ატვირთვის ნაწილებად წაკითხვა chunked HTTP-ს არ მოითხოვს

არა. კლიენტს შეუძლია დიდი ფაილის წაკითხვა პატარა ბუფერებში და მისი გაგზავნა ცნობილი Content-Length-ით. შემოსაზღვრული წაკითხვები მეხსიერების ხარჯვას აკონტროლებს; HTTP ჩარჩოვნება მიმღებს ეუბნება, სად მთავრდება მოთხოვნის სხეული.

სტაბილური ფაილი, რომლის ბაიტური სიგრძე HTTP ბიბლიოთეკამ იცის, განსხვავდება გენერატორისგან, რომელიც უცნობ რაოდენობის მონაცემებს ქმნის. ორივე წყაროსთვის გამოიყენეთ ბიბლიოთეკის მიერ მხარდაჭერილი სხეულის ინტერფეისი. არ არის საჭირო მთელი ფაილის ერთ სტრიქონში შეკრება მხოლოდ სიგრძის მისაცემად.

HTTP/1.1-ისთვის შეამოწმეთ რეალურად გაგზავნილი ჩარჩოვნება: Content-Length ან chunked გადაცემის კოდირება პროტოკოლის წესების მიხედვით. Chunked კოდირება ზომის ნიშნებს ფაილის შიგთავსის გარეთ ამატებს. ნუ შეაერთებთ წინააღმდეგობრივ ჩარჩოვნების ველებს და ნუ გამოიცნობთ სიგრძეს პროქსის ატვირთვის მიღებაში დასარწმუნებლად.

თუ პროქსის გავლით ატვირთვა ვერ მოხერხდა, ჩაწერეთ HTTP ვერსია, სხეულის წყარო და პირველი უარი. 411 პასუხი მიუთითებს სხვა გამოძიებაზე, ვიდრე სხეულის შუაში დახურული კავშირი. თუ სამაგიეროდ ავთენტიფიკაციის ხელახალი ცდები ჩავარდა, შეამოწმეთ შეიძლება თუ არა ატვირთვის სხეულის ხელახლა დაკვრა. აპლიკაციის წაკითხვის ბუფერის ზომის შეცვლამ შეიძლება მოთხოვნის ჩარჩოვნება ზუსტად ისე დატოვოს, როგორც იყო.

მარშრუტი მნიშვნელოვანია ამ დაკვირვებისთვის. ღია ტექსტით გადაცემა ატვირთვის HTTP ჩარჩოვნებას პროქსის უმჟღავნებს; ჩვეულებრივი ბოლოდან ბოლომდე HTTPS მას გვირაბში ათავსებს. HTTP/2 საკუთარ ჩარჩოვნებას იყენებს. ამიტომ Squid-ის ისტორიული შეზღუდვები განმარტავს გარკვეულ ძველ ჩავარდნებს და არა წესს, რომ დღევანდელი ყოველი პროქსი უარყოფს ნაკადოვან ატვირთვებს.