Как заставить Wget обрабатывать ответ HTTP 100-Continue? - PullRequest
Новая
       26

Как заставить Wget обрабатывать ответ HTTP 100-Continue?

1 голос
/ 24 сентября 2008

Я пытаюсь поместить HTML (содержащийся в файле) в URL, используя Wget , например: 

wget -O- --debug
     --header=Content-Type:text/html
     --post-file=index.html
     http://localhost/www/encoder.ashx

URL-адрес, на который публикуется HTML, является конечной точкой веб-приложения, реализованной с использованием ASP.NET. Сервер отвечает ответом 100 (Продолжить) , и Wget просто останавливается на месте, вместо того, чтобы продолжить с ответом real , за которым должно следовать следующим. *

Можно ли как-то сказать Wget передать ответ 100 (Продолжить) или это какое-то известное ограничение инструмента?

Примечания:

  • Я заметил, что Wget никогда не отправляет заголовок Expect: 100-Continue так технически сервер не должен быть выдача ответа 100 (Продолжить).

    ОБНОВЛЕНИЕ: Похоже, это возможно, согласно §8.2.3 RFC 2616 (протокол передачи гипертекста - HTTP / 1.1) :

    Исходному серверу НЕ СЛЕДУЕТ отправлять ответ 100 (продолжение), если сообщение запроса не включает заголовок запроса Expect поле с ожиданием "100-продолжить", и НЕ ДОЛЖНЫ отправлять 100 (Продолжить) ответ, если такой запрос исходит от HTTP / 1.0 (или ранее) клиент. Из этого правила есть исключение: для совместимость с RFC 2068, сервер МОЖЕТ отправить 100 (Продолжить) статус в ответ на запрос HTTP / 1.1 PUT или POST, который не включать поле заголовка запроса Expect с "100- продолжить "ожидание. Это исключение, целью которого является чтобы минимизировать любые задержки обработки клиента, связанные с статус необъявленного ожидания 100 (Продолжить), применяется только к HTTP / 1.1 запросы, а не запросы с любым другим HTTP- значение версии.

  • cURL не имеет проблем с такой транзакцией. Это отправляет заголовок Expect: 100-Continue и продолжил с 100 (Продолжить) ответ на настоящий.

Для получения дополнительной информации вот полная трассировка отладки транзакции от вызова, показанного выше: 

Setting --post-file (postfile) to index.html
Setting --header (header) to Content-Type:text/html
DEBUG output created by Wget 1.10 on Windows.

--13:29:17--  http://localhost/www/encoder.ashx
           => `-'
Resolving localhost... seconds 0.00, 127.0.0.1
Caching localhost => 127.0.0.1
Connecting to localhost|127.0.0.1|:80... seconds 0.00, connected.
Created socket 296.
Releasing 0x01621a10 (new refcount 1).

---request begin---
POST /www/encoder.ashx HTTP/1.0
User-Agent: Wget/1.10
Accept: */*
Host: localhost
Connection: Keep-Alive
Content-Type: text/html
Content-Length: 30984

---request end---
[writing POST file index.html ... done]
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 100 Continue
Server: ASP.NET Development Server/9.0.0.0
Date: Wed, 24 Sep 2008 11:29:17 GMT
Content-Length: 0

---response end---
100 Continue
Closed fd 296
13:29:17 ERROR 100: Continue.

1 Ответ

1 голос
/ 25 сентября 2008

Я посмотрел исходный код wget для Windows, и насколько я могу судить, выходные данные отладки исходят из общего состояния ошибки, когда wget не удается правильно проанализировать ответ. Похоже, это всего лишь ограничение wget, поэтому вам, вероятно, придется использовать curl или какой-либо другой метод, чтобы избежать возникновения этой проблемы.

...