HTTP վերբեռնման դադարներ և Expect: 100-continue

Կապը բացվում է։ Հարցման վերնագրերը դուրս են գալիս։ Թվում է՝ ֆայլը չի շարժվում։ Մեկ բացատրություն այն է, որ հաճախորդը սպասում է Expect: 100-continue-ի պատասխանին՝ նախքան իր մարմինն ուղարկելը։

Մեխանիզմը թույլ է տալիս ստացողին մերժել հարցումը ըստ վերնագրերի՝ նախքան հնարավոր մեծ վերբեռնումն ուղարկելը։ Սովորական հաջող հաջորդականությունը հետևյալն է՝

request headers → 100 Continue → request body → final response

100-ը տեղեկատվական է. այն թույլ է տալիս հաճախորդին շարունակել, բայց չի նշանակում, որ ֆայլը պահվել է կամ հավելվածի գործողությունը հաջողվել է։ HTTP 417 վերադարձնող Git push-ը սպասումի ձախողման մեկ կոնկրետ դեպք է։

Պարզեք, թե ինչ պատասխան է ստացել հաճախորդը

curl-ը տրամադրում է առանձին սպասման կարգավորում expect-continue-ի համար։ Եթե այդ libcurl սպասումը լրանում է առանց սպասվող պատասխանի, այն մարմինը միևնույն է ուղարկում է. լրանալը ինքնաբերաբար ամբողջ փոխանցման ձախողում չէ։ Կարգավորումն առանձին է ամբողջական փոխանցման համար թույլատրված ժամանակից։ Վերջինիս ավելացումը կարող է նույն սկզբնական դադարը թողնել անբացատրելի։

Պարզեք նաև, թե որ HTTP զրույցն է կրում Expect-ը։ HTTPS նպատակակետին սովորական CONNECT-ի դեպքում կայքի վերբեռնման փոխանակումը TLS-ի ներսում է. առաջադիմող վստահված սպասարկիչը պարզապես չի ստուգում դրա ներքին սպասումի վերնագիրը։ Ընդհատման կամ բաց տեքստով փոխանցման ուղին տարբեր է։

Սպասումը հեռացնելը կարող է լինել համատեղելիության գիտակցված ընտրություն, բայց դա նշանակում է, որ հաճախորդը կարող է սկսել մեծ մարմին ուղարկել՝ նախքան վաղ մերժման մասին իմանալը։ Համեմատեք այդ վարքը իրական պահանջի հետ։ Մի նկարագրեք հին վստահված սպասարկիչի համար պատմական լուծումը որպես վերնագիրը յուրաքանչյուր վերբեռնումից հեռացնելու համընդհանուր հրահանգ։