PUT et POST sont deux méthodes HTTP différentes.

oui c'est juste que depuis le début le 'put' de nspeed faisait un POST.
avec la v0.10 j'ai changé cela. 'put' fait maintenant un 'PUT' et j'ai ajouté 'post' si on veut faire un POST. histoire d'être cohérent avec le protocole HTTP.

Sinon, j'avais déjà relevé le comportement peu intuitif de la commande "nspeed server" sans l'option -a, ou avec une interface.
Le readme dit que par défaut ça utilise 127.0.0.1, mais ça dépend des machines :
 - sur WSL j'ai 127.0.0.1 par défaut, et "nspeed server -6" échoue (mais "nspeed server -a ::1" fonctionne)
 - sous Linux et Windows, j'ai ::1 par défaut (IPv6 seulement), et "nspeed server -4" fonctionne pour avoir l'IPv4
De même "-a lo" ou toute autre interface semble choisir IPV6.
Certes on peut :
 - utiliser -a "" ou -a :: pour écouter sur toutes les interfaces en IPv4 et IPv6.
 - donner deux commandes : "nspeed server -a enp5s0 -4 server -a enp5s0 -6" ou "nspeed server -a 127.0.0.1 server -a ::1"
De même -

oui c'est "normal". 'nspeed server' fait par défaut 'nspeed server -a localhost' (comme le montre 'nspeed server -h')
il y une reso dns pour résoudre 'localhost'. Suivant l'hôte ca peut ne pas fonctionner pour IPv6, sans doute le cas de WSL ("ping -6 localhost" devrait avoir le même probleme non ?)
Je pourrais forcer pour résoudre directement localhost en 127.0.0.1 et ::1 pour éviter ce genre de problème mais c'est bien aussi de pas toujours s'adapter aux OS mal configurés ? j'ai pas tranché encore la.

cf aussi le CHANGELOG.md , il y a une note a ce sujet ( qui n'est plus trop a jour car cela bind bien en IPv6 par défaut si la réso dns retourne ::1).

Pour écouter a la fois en IPv6 et IPv4 avec une seule commande 'server' ou plus généralement sur plus d'une adresse, il n'y a que "" qui fonctionne. Pour que ca fonctionne avec localhost ou n'importe quelle interface, il faudrait faire un SO_BINDTODEVICE ce qui n'est pas supporter directement en Go car ce n'est pas multiplateforme de base (ca a peut etre changé depuis , je n'ai pas creusé plus - c'est une histoire de "dual stack socket", entres autres). Ce n'est pas crucial pour le moment mais c'est dans la todo  list.
Il est vrai que ca serait pratique de pouvoir 'nspeed server -a eth0' pour écouter sur toutes les IP (une ou plusieurs v4 et et une ou plusieurs v6) d'eth0.

Je pourrais forcer pour résoudre directement localhost en 127.0.0.1 et ::1 pour éviter ce genre de problème mais c'est bien aussi de pas toujours s'adapter aux OS mal configurés ? j'ai pas tranché encore la.

Tu connais la maxime des vieux barbus : you ask for it, you have it.
Si c'est mal configuré c'est pas de ton ressort. Ensuite, tu tranches comme tu veux.

Je sais pas trop ou tu veux aller avec l'outil, Je me doute que cela entre dans le cadre des outils de mesures pour les box.
Mais si tu te coltines une dual stack, je vois pas l'avantage concurrentiel avec iperf3 ou autres outils et cela te double le boulot pour réinventer la roue, autant que tu prennes les sources de iperf3 et en copie des bouts de code.
Par contre, si tu restreins à IPv6 et intègre les standards encore en devenir, là tu as un vrai avantage concurrentiel, avec cet outil, pendant que les autres continuent à se coltiner une dual stack et perdre leur temps, toi tu peux continuer à avancer.

Je l'accorde, il ne dois pas exister beaucoup de machine en mono stack exclusivement IPv6. Je vois bien ma dernière installation de Debian bookworm installe IPV4 que on le veuille ou pas, il faut ensuite tout désinstaller pour ne garder que une mono stack IPV6

update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-7-g3e22883-dirty)

- synchro interne quand on fait des get/put sur le(s) server(s) de la meme commande (plus besoin de -w 1. Dans de rares cas cela peut ne pas fonctionner, je n'ai pas encore trouvé la raison)
- changement de logique quand on combien des commandes 'qui ne s’arrêtent jamais' comme 'server' avec des commandes qui terminent comme 'get'. plus besoin de "server -n 1" pour faire un test local par exemple. le(s) serveur(s) s'arreteront quand il n'y a plus d'activité.
- épuration de l'affichage par défaut
- update lib http/3

on peut donc maintenant faire, des tests du genre:
./nspeed get http://localhost:7333/20g server
./nspeed get localhost:7333/20g server -self
./nspeed get -http3 localhost:7333/20g server -http3
ou
./nspeed get -n 2 http://localhost:7333/20g server put -n 4 http://localhost:7333/ 10g
et meme un truc du genre:
./nspeed get http://localhost:7333/20g server get -http3 localhost:7333/20g server -http3


update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-10-gfc2875e)

- modifications du client http (get/post/put):
  - l'option --http11 est renommée --http1.1 - fonctionnement inchangé.
  - ajout de l'option --http2 pour imposer/forcer l'utilisation de HTTP/2. Contrairement a curl par exemple, si le serveur en face ne supporte pas HTTP/2 la commande va échouer. alors que curl --http2 va tenter HTTP/2 en 1er mais fallback en HTTP1.1.

>   - ajout de l'option --http2 pour imposer/forcer l'utilisation de HTTP/2.

tu peux la renommer "--forcehttp2" ?

oui éventuellement avant la release v1.0.
J'ai été au plus rapide parce que j'en avais besoin pour un cas concret.
Il y aura a un moment une passe de réflexion sur toutes les options, leur noms, etc donc je verrai a ce moment.

Peut-être se baser sur les option CURL quand elles existent déjà chez CURL ?

dans la mesure du possible oui.