HTTP ატვირთვის შეჩერებები და Expect: 100-continue

კავშირი იხსნება. მოთხოვნის სათაურები გადის. ჩანს, რომ ფაილი არ მოძრაობს. ერთი ახსნაა, რომ კლიენტი ელოდება პასუხს Expect: 100-continue-ზე, სანამ თავის სხეულს გაგზავნის.

მექანიზმი საშუალებას აძლევს მიმღებს, სათაურების მიხედვით უარყოს მოთხოვნა მანამ, სანამ შესაძლოა დიდი ატვირთვა გაიგზავნება. ჩვეულებრივი წარმატებული თანმიმდევრობაა:

request headers → 100 Continue → request body → final response

100 საინფორმაციოა: ის კლიენტს გაგრძელების ნებას აძლევს, მაგრამ არ ნიშნავს, რომ ფაილი შენახულია ან აპლიკაციის ოპერაცია წარმატებით დასრულდა. Git push, რომელიც აბრუნებს HTTP 417-ს, მოლოდინის წარუმატებლობის ერთი კონკრეტული შემთხვევაა.

გაარკვიეთ, რომელი პასუხი მიიღო კლიენტმა

curl გთავაზობთ expect-continue-ისთვის ცალკე ლოდინის პარამეტრს. თუ ეს libcurl-ის ლოდინი მოსალოდნელი პასუხის გარეშე ამოიწურება, ის მაინც აგზავნის სხეულს; ამოწურვა ავტომატურად მთელი გადაცემის წარუმატებლობა არ არის. პარამეტრი განცალკევებულია სრული გადაცემისთვის დაშვებული დროისგან. ამ უკანასკნელის გაზრდამ შეიძლება იგივე საწყისი შეჩერება აუხსნელად დატოვოს.

ასევე გაარკვიეთ, რომელი HTTP საუბარი ატარებს Expect-ს. HTTPS დანიშნულებისკენ ჩვეულებრივი CONNECT-ისას საიტის ატვირთვის გაცვლა TLS-ის შიგნითაა; გამტარი პროქსი უბრალოდ არ ამოწმებს მის შიდა მოლოდინის სათაურს. ჩარევის ან ღია ტექსტით გადაცემის გზა სხვაა.

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