[ThunderLord]

Bonsoir à tous,

Voilà depuis quelques temps , j'ai installé FreeBSD et j'ai un souci avec netcat.

Je souhaite envoyer des donnés à un serveur et pouvoir récupérer la réponse.

Lorsque je tape ma requête manuellement, il n'y a aucun problème et ma réponse est affiché dans la console.

Cependant, je souhaite automatiser ceci, en préparant les commandes à envoyer préalablement dans un fichier et le transmettre à netcat, puis récupérer la réponse dans la console.

Petite citation du manuel de netcat :

TALKING TO SERVERS
     It is sometimes useful to talk to servers ``by hand'' rather than through
     a user interface.  It can aid in troubleshooting, when it might be neces-
     sary to verify what data a server is sending in response to commands
     issued by the client.  For example, to retrieve the home page of a web
     site:

           $ echo -n "GET / HTTP/1.0\r\n\r\n" | nc host.example.com 80

     Note that this also displays the headers sent by the web server.  They
     can be filtered, using a tool such as sed(1), if necessary.

Je décide donc d'exécuter cette commande, mais rien ne se passe et le shell me rend le prompt au bout de quelques secondes.

Voilà un exemple de résultat :

> echo -n "GET / HTTP/1.0\r\n\r\n" | nc google.com 80
>

En redirigeant l'output de la commande dans un fichier, j'obtiens un résultat similaire : le fichier est effectivement crée mais il est vide. Pareil pareil en lançant la commande suivante :

nc google.com 80 < request

Où request est le ficher qui contient la commande a envoyé. Enfin en spécifiant l'option -v , netcat ne me renvoie qu'une confirmation qu'il s'est bien connecté à l'hôte distant.

Merci d'avance pour m'aider à résoudre ce problème,

ThunderLord

[_o_]

$ echo -n "GET / HTTP/1.0\r\n\r\n" | nc host.example.com 80

Le résultat est symptomatique : plusieurs secondes d'attente, puis un time-out. Dans le cas des requêtes HTTP, c'est en général parce que le serveur attend la fin de la requête, fin normalement indiquée par un double retour-chariot. Et pour s'en convaincre, il suffit de ne taper qu'une partie de la commande :

Code:

$ echo -n "GET / HTTP/1.0\r\n\r\n"

Le résultat est édifiant. Bref, pas grand chose à voir avec FreeBSD (en supposant des versions identiques d'echo, voir du shell si echo est un built-in), pas plus qu'avec netcat (à part son manuel, mais ça peut venir là aussi d'une version différente d'echo par son auteur). Bref :

Code:

$ echo -e "GET / HTTP/1.0\r\n\r\n"

ou, (beaucoup) mieux :

Code:

$ printf "GET / HTTP/1.0\r\n\r\n"

Note que le comportement restera totalement identique quoique tu fasses des entrées/sorties (pipe, redirection vers ou depuis un fichier, etc...).

[ThunderLord]

Merci _o_ pour une réponse si rapide et instructive, en effet j'ai remplacé echo par printf et ça fonctionne.

Par contre, si je souhaite utiliser un fichier de commande comme entrée, ça n'affiche rien même si j'ai effectivement inséré 2 retours charriots à la fin du fichier.

[_o_]

Par contre, si je souhaite utiliser un fichier de commande comme entrée, ça n'affiche rien même si j'ai effectivement inséré 2 retours charriots à la fin du fichier.

Pas trop d'idée. Sauf éventuellement que ton éditeur de texte peut te faire une farce en supprimant les retour-chariots à la sauvegarde. Mais je n'ai pas ce genre de problème, une ligne vide dans le fichier suffit pour que netcat reçoive une réponse du serveur.

[ThunderLord]

Je ne pensait pas que ce soit mon éditeur de texte (nano en l'occurrence)  qui soit à l'origine de ce problème, car l'affichage du contenu du fichier est identique au résultat de la commande :

Code:

$ printf "GET / HTTP/1.0\r\n\r\n"

En effet j'obtiens ceci :

Code:

> cat request
GET / HTTP/1.1


> 

On remarque bien que les 2 retours charriots sont présents à la fin du fichier. Après analyse du flux TCP avec wireshark, j'ai pourtant remarqué une subtile différence par rapport à la commande précédente.
En effet voici ce que j'envoie au serveur :

Code:

00000000  47 45 54 20 2f 20 48 54  54 50 2f 31 2e 31 0a 0a GET / HT TP/1.1..
00000010  0a

Ce qui est assez étrange car il y a 3 Line Feeds (0a) à la fin mais aucun retour charriot (0d).

Si c'est donc nano qui fait cette modification, quel autre éditeur de texte me recommander-vous qui n'altère pas les retours charriots ?

[arkhard]

printf "texte \n" > fichier
ca devrait te mettre les retours dans le fichier de sortie.

Sinon ca fonctionne avec emacs .

Edit : emacs altère aussi les retours chariots.

[ThunderLord]

Oui j'ai essayé avec emacs et j'ai le même résultat, 3 line feeds à la fin de la transmission et pas un seul retour charriot.

La seule solution qui fonctionne , c'est de mettre la commande dans le fichier avec la fonction printf :

Code:

printf "GET / HTTP/1.0\r\n\r\n" > request
> cat request | nc google.com 80
HTTP/1.1 302 Found
Location: http://www.google.fr/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=032455e2289bf03d:TM=1226840041:LM=1226840041:S=ltFhW_3uk4ww5cmB; expires=Tue, 16-Nov-2010 12:54:01 GMT; path=/; domain=.google.com
Date: Sun, 16 Nov 2008 12:54:01 GMT
Server: gws
Content-Length: 218

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.fr/">here</A>.
</BODY></HTML>
> 

Mais bon créer un fichier en ajoutant les commande lignes par ligne avec la fonction printf ce n'est surement pas le moyen le plus commode.
Quelqu'un aurait-il une idée pour le faire avec un éditeur de texte ?

[_o_]

Ce qui est assez étrange car il y a 3 Line Feeds (0a) à la fin mais aucun retour charriot (0d). Si c'est donc nano qui fait cette modification, quel autre éditeur de texte me recommander-vous qui n'altère pas les retours charriots ?

Rien d'étrange à ça. Sous Unix, un retour chariot, c'est 0x0a. Sous Windows, c'est 0x0d puis 0x0a.
Du coup, avec printf "\n", tu as un retour chariot Unix. Avec printf "\r\n", tu as un retour chariot Windows.
Du côté des éditeurs de texte, logiquement, sous Unix les éditeurs génèrent des retour-chariots Unix, mais s'ils sont assez élaborés, il n'y a pas de problème pour leur faire changer leur comportement. Par exemple, sous vim, c'est la commande :set fileformat=[unix|dos].

Cela dit, même si la norme HTTP mentionne qu'il faut spécifier des \r\n dans les requêtes, il semble que ça ne pose pas de problème d'utiliser des \n simples, en tout cas sur les Apache que j'ai sous la main. Peut-être que d'autres serveurs sont moins souples.

En passant, je te conseille tout de même, si tu n'as que du HTTP à bricoler, à te pencher sérieusement sur cURL.

[ThunderLord]

il semble que ça ne pose pas de problème d'utiliser des \n simples, en tout cas sur les Apache que j'ai sous la main. Peut-être que d'autres serveurs sont moins souples.

En effet, j'ai essayé sur d'autres serveurs et de simples \n suffisent amplement. De plus merci _o_ pour le lien, je ne connaissais par cURL et il a l'air d'offrir pas mal de fonctionnalités.