Question

Je suis en train d'établir une connexion HTTP avec un serveur Web IIS et d'envoyer une demande POST avec les données codées à l'aide de Transfer-Encoding: chunked. Lorsque je le fais, IIS ferme simplement la connexion, sans message d'erreur ni code d'état. Selon les spécifications HTTP 1.1 ,

  

Toutes les applications HTTP / 1.1 DOIVENT être en mesure de recevoir et de décoder le "chunked". codage de transfert

donc je ne comprends pas pourquoi il (a) ne gère pas cet encodage et (b) n’envoie pas de code d’état. Si je modifie la demande d'envoi de Content-Length plutôt que de Transfer-Encoding, la requête aboutit, mais ce n'est pas toujours possible.

Lorsque j'essaie de faire la même chose contre Apache, j'obtiens un "411 Length required". statut et un message disant "encodage de transfert en bloc interdit".

Pourquoi ces serveurs ne prennent-ils pas en charge cet encodage?

Était-ce utile?

La solution

Je crois comprendre que le codage fragmenté ne peut être utilisé que dans une réponse HTTP. Un corps de requête fragmenté aurait la propriété d'être incompatible avec un serveur 1.0, et dans tous les cas, il n'y aurait aucun moyen qu'un agent utilisateur sache que le serveur était un serveur 1.0 avant d'avoir déjà envoyé la demande.

Mais je conviens que la documentation ne le dit pas clairement.

Autres conseils

Regardez votre client.

IIS & amp; Apache prend en charge les requêtes POST utilisant un codage de transfert en bloc. Vous pouvez le vérifier à l'aide de l’ utilitaire curl :

.
curl <upload-url> --form "upfile=@<local_file>" --header "Transfer-Encoding: chunked"

Vérifiez que le transfert est fractionné à l'aide de Wireshark

.

Cela va dans les deux sens. essayez de télécharger une image 2MB ++ sur photobucket et enregistrez-la. leurs uploads uploadés sur leurs serveurs apache.

Je suppose seulement qu'ils ne l'ont pas mis en œuvre pour des raisons de sécurité. Dans une solution naïve, il serait facile de mettre en place une attaque DOS en lançant plusieurs transferts fragmentés qui ne se terminent jamais. Et une solution complexe qui pourrait expliquer l'attaque du DOS ne vaut probablement pas la peine.

Bien sûr, je ne peux pas parler pour Apache ou IIS, vous pourrez peut-être contacter directement l'équipe Apache via: http://httpd.apache.org/bug_report.html

Je suis d'accord avec MarkR sur le fait que je pensais toujours que l'encodage en bloc ne pouvait être utilisé que comme réponse, mais la documentation donne à penser qu'il peut être utilisé dans une requête ou une réponse.

Cette commande est venue à mon secours!

  

C: \ Windows \ System32 \ Inetsrv \ Appcmd.exe set config -section: httpCompression

    - [name = 'gzip']. staticCompressionLevel: 9 - [name = 'gzip']. dynamicCompressionLevel: 4

a sauvé ma journée ... espérons que cela aidera quelqu'un comme moi!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top