Паузы при 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; пересылающий прокси не просто просматривает внутренний заголовок ожидания. Путь перехвата или пересылки открытым текстом отличается.
Удаление ожидания может быть осознанным выбором совместимости, но это означает, что клиент может начать отправлять большое тело, ещё не узнав о раннем отказе. Сравните такое поведение с фактическим требованием. Не описывайте историческое решение для старого прокси как универсальное указание удалять заголовок из каждой загрузки.