Upload de fichier par HTTP

Bonjour et merci d'avance pour les éclaircissement que vous voudrez bien m'apporter.

Je vous expose mon pb : J'ai un cgi qui réceptionne un POST d'un formulaire comprenant un input de type file (upload de fichier).
Je n'arrive pas à interrompre l'envoi d'un fichier de taille volumineuse :
- soit je bloque la requête au niveau de mon cgi
- soit je bloque au niveau de mon serveur web (LimitRequestBody sous apache)

Dans les deux cas, si la personne qui répond à mon formulaire essaye d'uploader un fichier de 2Go soit il va recevoir une erreur de type timeOut soit une erreur 413 requête trop grande et dans les deux cas cela sera après un temps d'attente qui peut être très long (le temps que le navigateur upload le fichier de 2Go?...).

D'où ma question : est-il possible d'interrompre la requête depuis le serveur avant que le client ait commencé à uploader le fichier?

J'ai fait des captures de communication réseau entre mon client et mon serveur et je ne vois passé ma requête POST HTTP depuis le client vers le serveur qu'une fois que le fichier joint a été transférer au serveur par une succession de trames TCP. -> le serveur web doit donc recevoir ces premières trames et les garder en cache le temps que la requête soit complète. Cela me semble étonnant car il semble alors que le DDOS est à portée de main. par exemple si j'essaye de mettre en avatar de mon profil sur développez.com un fichier de 2Go, mon navigateur mouline et je suppose que si on est une dizaine de personne qui essayent de faire ça en même temps le serveur risque rapidement de ne plus répondre à personne...

Citation:

---

Envoyé par tenpigs

J'ai fait des captures de communication réseau entre mon client et mon serveur et je ne vois passé ma requête POST HTTP depuis le client vers le serveur qu'une fois que le fichier joint a été transférer au serveur par une succession de trames TCP....

---

Pas possible. Avec quel outil as-tu fait tes captures ? HTTP est un protocole strict dans lequel le client envoie les en-têtes avant les données. Dans cette requête, ce qu'il faut voir c'est si un Content-Length est envoyé dans les en-têtes. Avec cette info, le serveur doit pouvoir interrompre l'upload avant que le fichier ne soit envoyé, mais dans le cas où cet en-tête est absent, on ne peut rien faire : il faut attendre que le serveur ait reçu les données pour qu'il soit en mesure de vérifier la taille de la requête. Si tu te retrouves dans le dernier cas, le comportement observé est parfaitement normal et ne peut malheureusement pas être modifié.

effectivement ça semble logique d'envoyer les entêtes avant les données ^^
J'ai fait mes captures avec Wireshark mais je n'avais pas regardé au bon endroit.
Wireshark mentionne l'appel en tant que http qu'une fois que toutes les données de la requête ont été envoyées.

Donc effectivement le client envoi bien les en-têtes en premier, à ce moment mon apache répond par une erreur 513 si le fichier est trop gros, le souci est du coup côté client qui continue de faire son upload et ne prend pas en compte la réponse qu'il vient de recevoir... ça serait ie qui ne gèrerait pas l'interruption par le serveur au cours de son envoi, je vais tester avec d'autres navigateurs pour voir ce qu'il en est.

en tout cas merci _Mac_ pour ton aide.

Citation:

---

Envoyé par tenpigs

Wireshark mentionne l'appel en tant que http qu'une fois que toutes les données de la requête ont été envoyées.

---

Oui, je ne sais pas pourquoi. Sûrement qu'il a besoin de toute la trace pour savoir. C'est surprenant car il me semble que son filtre HTTP s'appuie uniquement sur le numéro de port :roll:

Citation:

---

Envoyé par tenpigs

Donc effectivement le client envoi bien les en-têtes en premier, à ce moment mon apache répond par une erreur 513 si le fichier est trop gros, le souci est du coup côté client qui continue de faire son upload et ne prend pas en compte la réponse qu'il vient de recevoir...

---

Tu veux dire que dans ce cas-là, Apache n'envoie pas la séquence FIN-ACK pour terminer la connexion ? Si Apache fait du keep-alive, c'est possible, et dans ce cas ça pourrait bien venir du navigateur. Si c'est possible, essaie de désactiver le keep-alive dans Apache et vois si le comportement reste le même.

Le filtre http doit être un peu plus complexe que "prendre ce qui passe sur le port 80", tout ce qui est ack, segments de PDU sont marqués TCP alors qu'ils passent sur le port http (80).

J'ai désactivé le keep-alive sur mon apache, ça n'a aucun effet. Dans les deux cas apache renvoi bien un FIN-ACK. Après quelques tests firefox 3, ie 6 et 7 n'ont pas l'air de gérer cette interruption (ils continuent de mouliner pour envoyer leur fichier). Seul opera 9 et 10 s'interrompent tout de suite pour afficher l'erreur 413 qu'ils reçoivent.

Bon, ben, je crois qu'on a une réponse malheureusement non satisfaisante :aie:

Que fait le serveur après qu'il a envoyé le FIN-ACK ? Il continue d'accuser réception des paquets inutiles que lui envoie le navigateur ?

Le serveur s'en va vers de nouveaux horizons, seul le client ne peut se résoudre à rompre cette liaison dans laquelle il s'était tant investit...

Du point de vue d'admin du serveur c'est satisfaisant en fait, j'ai la possibilité de limiter la taille des uploads donc une mauvaise manip utilisateur ne risque pas de mettre mon apache dans les choux... par contre pour l'utilisateur qui a fait la mauvaise manip et qui a posté son dvdrip au lieu d'un jpg de 20Ko c'est tout de suite moins satisfaisant :aie:
merci encore pour ton aide