Comment faire en sorte que Wget gère une réponse HTTP 100-Continue?

Question

J'essaie de publier un fichier HTML (contenu dans un fichier) sur une URL à l'aide de Wget comme ceci:

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

L'URL à laquelle le code HTML est publié est un noeud final d'application Web implémenté à l'aide d'ASP.NET. Le serveur répond avec un 100 (Continuer) réponse et Wget s’arrête simplement sur ses traces plutôt que de continuer avec la vraie réponse que devrait suivre ensuite.

Peut-on dire à Wget de gérer une réponse de 100 (Continuer) ou s'agit-il d'une limitation bien connue de l'outil?

Notes:

• J'ai remarqué que Wget n'envoie jamais l'en-tête Expect: 100-Continue afin techniquement, le serveur ne devrait pas être émettre une réponse 100 (Continuer).

  UPDATE: Cela semble possible, comme indiqué dans & # 167; 8.2.3 de la RFC 2616 (protocole de transfert d'hypertexte - HTTP / 1.1) :

    

  Un serveur d'origine NE DEVRAIT PAS envoyer de réponse 100 (Continuer) si   le message de requête n'inclut pas d'en-tête de requête Expect   champ avec le " 100-continue " attente et NE DOIT PAS envoyer de message   100 (Continuer) réponse si une telle demande provient d'un HTTP / 1.0   (ou plus tôt) client. Il existe une exception à cette règle: pour   compatibilité avec la RFC 2068, un serveur PEUT envoyer un 100 (Continuer)   statut en réponse à une requête HTTP / 1.1 PUT ou POST qui   ne pas inclure de champ d’en-tête de demande Expect avec le signe "100"   continuer " attente. Cette exception, dont le but est de   minimiser les retards de traitement du client associés à une   attente non déclarée pendant le statut 100 (Continuer), s'applique uniquement à   Requêtes HTTP / 1.1, et pas avec des requêtes HTTP   valeur de version.

• cURL n'a pas de problème avec une telle transaction. Il envoie un en-tête Expect: 100-Continue . et continué avec 100 (Continuer) réponse sur le vrai.

Pour plus d'informations, voici la trace de débogage complète de la transaction à partir de l'appel indiqué ci-dessus:

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.

Answer 1

J'ai examiné le code source de wget pour Windows et, autant que je sache, le résultat du débogage provient de la condition d'erreur générique lorsque wget ne parvient pas à analyser correctement la réponse. On dirait que ceci n’est qu’une limitation de wget, vous devrez donc probablement utiliser curl ou une autre méthode pour éviter ce problème.