Паузи під час HTTP-завантаження та Expect: 100-continue
Розпізнавайте обмін Expect: 100-continue і відрізняйте його коротку точку рішення від завантаження, що застрягло під час передавання даних.
З'єднання відкривається. Заголовки запиту виходять. Здається, що файл не рухається. Одне пояснення — клієнт чекає на відповідь на Expect: 100-continue, перш ніж надіслати тіло.
Механізм дозволяє одержувачу відхилити запит за його заголовками до надсилання потенційно великого завантаження. Звичайна успішна послідовність:
request headers → 100 Continue → request body → final response100 є інформаційним: він дозволяє клієнту продовжити, але не означає, що файл збережено або операція застосунку виконалася успішно. Git push, що повертає HTTP 417, — це один конкретний випадок невиправданого очікування.
Визначте, яку відповідь отримав клієнт
| Спостереження | Що досліджувати |
|---|---|
| 100 Continue | Клієнт може продовжити з тілом |
| Остаточна відмова до тіла | Операцію відхилено на етапі заголовків |
| Немає очікуваної проміжної відповіді | Політика очікування клієнта й обробка на цьому шляху |
curl має окреме налаштування очікування expect-continue. Якщо це очікування libcurl спливає без очікуваної відповіді, тіло все одно надсилається; спливання саме по собі не є невдалою всією передачею. Налаштування відокремлене від часу, дозволеного на повну передачу. Збільшення останнього може залишити ту саму початкову паузу непоясненою.
Також визначте, у якій HTTP-розмові передається Expect. За звичайного CONNECT до HTTPS-призначення обмін завантаження сайту відбувається всередині TLS; пересилаючий проксі не просто переглядає внутрішній заголовок очікування. Шлях перехоплення або пересилання відкритим текстом інший.
Вилучення очікування може бути свідомим вибором сумісності, але це означає, що клієнт може почати надсилати велике тіло, ще не дізнавшись про ранню відмову. Порівняйте таку поведінку з фактичною вимогою. Не описуйте історичне рішення для старого проксі як універсальну вказівку вилучати заголовок з кожного завантаження.