Suite à mon petit article (https://links.thican.net/?OIlYuQ) sur le même principe (des requêtes HTTP), mais en utilisant telnet, voici donc une autre version bien plus propre, avec curl.
Pour rappel :
Utilisons donc quelques variables pour simplifier les envois (c'est du bash, au fait)
- host : c'est le nom de domaine du site web à contacter (pour utiliser avec la variable HOST),
- port : le port du serveur distant (port 80 très souvent, doit être un nombre entre 1 et 65 535 inclus),
- url : l'url de la page web à joindre, (sous la forme "/index.html", avec un '/' au début),
- getVars et postVars : la suite de variables qui vont être envoyées au serveur web, dans les requêtes GET et POST. (ces infos doivent être sous la forme "name=toto&code=2&update&field=text") ; dans une requête GET, postVars sera ignorée.
Attention : la variable "host" est obligatoire (le port est par défaut à "80" si la variable est vide).
Requête GET : curl --include http://${host}:{port:-80}/${url}?{getVars}
Requête POST : curl --include --data ${postVars} http://${host}:{port:-80}/${url}?{getVars}
That's it!
Concrètement, la différence entre telnet et curl, elle se réside uniquement dans votre démarche d'apprentissage et de compréhension.
Si vous voulez apprendre, modifier des données pour faire des tests, avoir un contrôle un peu plus poussé sur vos données, utilisez donc telnet.
Par contre, si vous voulez quelque chose qui fasse son boulot, simplement, avec le moins d'erreurs possible car maintenu à jour, sans prise de tête, tournez donc vers curl.
EDIT: une méthode, plus simple et plus "propre" à utiliser, avec curl : http://links.thican.net/?wGhHkw
Si vous avez besoin de tester un serveur web sans utiliser un navigateur web (pour ainsi mieux voir ce qui est concrètement reçu et envoyé), voici un début d'aide :
On va donc utiliser telnet, un logiciel qui permet simplement de se connecter à une machine distant, sur le port souhaité, et d'envoyer simplement des paquets TCP.
Utilisons donc quelques variables pour simplifier les envois (c'est du bash, au fait)
- host : c'est le nom de domaine du site web à contacter (pour utiliser avec la variable HOST),
- port : le port du serveur distant (port 80 très souvent, doit être un nombre entre 1 et 65 535 inclus),
- url : l'url de la page web à joindre, (sous la forme "/index.html", avec un '/' au début),
- getVars et postVars : la suite de variables qui vont être envoyées au serveur web, dans les requêtes GET et POST. (ces infos doivent être sous la forme "name=toto&code=2&update&field=text") ; dans une requête GET, postVars sera ignorée.
Attention : la variable "host" est obligatoire (le port est par défaut à "80" si la variable est vide).
Pour les requêtes GET, voici donc :
{ echo -n -e "GET /${url}?${getVars} HTTP/1.1\nHOST: ${host}:${port:-80}\n\n"; sleep 0.5 } | telnet ${host} ${port:-80}
Pour les requêtes POST, il faut rajouter l'info de la variable "Content-Type: application/x-www-form-urlencoded" (attention, d'après cette page http://stackoverflow.com/questions/4007969/application-x-www-form-urlencoded-or-multipart-form-data s'il s'agit d'autres formes de données, mieux vaut modifier le contenu de cette variable), voici donc :
{ length=$(echo -n ${postVars} | wc -c --); echo -n -e "POST /${url}?${getVars} HTTP/1.1\nHOST: ${host}:${port:-80}\nContent-Type: application/x-www-form-urlencoded\nContent-Length: ${length}\n\n${postVars}"; sleep 0.5 } | telnet ${host} ${port:-80}
Voilà, c'est tout, simple non ? ;-)
Remarques :
- "Pourquoi le temps de pause dans telnet (sleep 0.5) ?"
Pour des raisons qui m'échappent, telnet va semble-t-il trop vite, et il envoit donc un paquet TCP avec le flag "RST" (Reset), ce qui coupe court le serveur distant, ainsi que l'affichage (même si le serveur distant a envoyé les données, telnet ne les affichera pas). Du coup, il se peut que vous tomber sur ce problème, si le serveur distant est long à répondre (grosse requête, trop de trafic, etc.), il faut donc augmenter le temps de pause. - "Pourquoi mettre un '/' en plus au début dans l'URL ("GET /${url}") ?"
Les '/' en doublon ne sont normalement pas gênants pour accéder à une ressource (essayez donc des URL avec une suite de '/', ça ne devrait pas poser problème). Effectivement, si le serveur distant ne gère pas correctement ces '/' doublons, il risque de râler, mais en tout cas, si le premier '/' est manquant (exemple "GET index.html"), là, c'est sûr, la requête est mauvaise. Donc, autant en mettre trop que pas assez. ;-)
@TODO:
TL;DR
Franchement, l'interface me plaît beaucoup, bien plus que KRiSS, qui fait déjà du bon boulot.
Je le ferai un peu plus tard. :-)
EDIT 2013-09-24: Non, il a trop de défauts, et surtout des trop mauvais défauts, pas des petites erreurs (version 0.81) :
- même si l'idée de créer des groupes en onglets est sympa, l'importation en OPML ne fonctionne tout simplement pas,
- aucun moyen pour exporter, et le fichier system/tabs.cfg (enfin, sans lire le code, je crois que la liste des flux RSS est stockée là dedans) est un blob binaire monstrueux, donc exportation 0,
- la séparation entre code exécutable (PHP, JS, et les templates HTML), et les données utilisateur n'existe pas, tout est mélangé, un coup on écrit à la racine (fichier pass.php), un coup c'est dans system (system/tabs.cfg), et enfin le dossier pour contenir les données des flux feeds_content ... bref, pas propre du tout,
- et enfin, le bouton flattr, pas statique du tout, avec connexion au serveur de flattr ... chouette pour la protection de la vie privée...
Dommage, peut-être à une autre fois.
Et encore un blocage ordonné par la justice irlandaise (officieusement, par les lobbys du disques), contre le site The Pirate Bay au niveau des FAI irlandais, et encore une fois, ce sera un blocage inefficace (sites miroirs, VPN, contournement DNS, etc.)
J'ai remarqué que le flux RSS créé par Pelican (http://blog.getpelican.com/) est mal formé, pleins de petites choses pas propres, bref, donc, à refaire.
Du coup, voilà de la documentation sur le flux RSS.
En prime, la RFC qui va bien : https://tools.ietf.org/html/rfc5005
ainsi que celle pour ATOM : https://tools.ietf.org/html/rfc4287
Tiens tiens, une implémentation de OpenPGP en JavaScript.
@TODO:
Vérifier les infos, et rédiger un résumé.
(via le Hollandais Volant http://lehollandaisvolant.net/index.php?mode=links&id=20130418183842)
Ah ouais, tout de suite, on voit que le principal but de Google, et donc de Chrome, c'est de détruire Apple, vu que WebKit est aussi utilisé par Safari, le navigateur web d'Apple.
La section 1.10 m'a choqué, faire exprès de détruire la compatibilité avec WebKit, et être sûr que Google sera le seul à pouvoir contribuer au projet ... Lamentable.
(via le Hollandais Volant http://lehollandaisvolant.net/index.php?mode=links&id=20130405113822)
Du CSS pour faire crasher Internet Explorer 9…
(via Sebsauvage http://sebsauvage.net/links/?FkxHRg)
En soit, l'idée est séduisante, mais j'ai pensé à la même chose que le commentateur nommé LeBret (http://bigbrowser.blog.lemonde.fr/2012/06/26/censure-pour-la-creation-dune-erreur-451-en-hommage-a-ray-bradbury/#comment-103251) :
« Fahrenheit 451 est une critique de la censure d’État.
Actuellement quand un État veut interdire certains sites, il filtre les réponses pour les remplacer par l’erreur 403.
Vous croyez vraiment que ces États vont utiliser une erreur 451 ?
Cela reviendrait de leur part à admettre qu’ils commettent une atteinte aux droits de l’Homme. »
Du coup, même si l'IETF l'accepte, et que c'est implémenté dans les navigateurs web et dans les serveurs web, ça m'étonnerait qu'on le voit.
TL;DR;
En complément : http://stackoverflow.com/questions/3146798/why-do-people-put-code-like-throw-1-dont-be-evil-and-for-in-front-of
Via SebSauvage http://sebsauvage.net/links/?lKi0mA
Le langage Python étant vraiment agréable, ça me tenterait bien.
@TODO
Franchement, ça me serait bien pratique, car mutt en ligne de commande, c'est bien, mais bon …
(Encore mieux, ce serait de faire ça en IMAP, pour pouvoir les lire avec un vrai client :-D)
Que voice, que voilà, Mitsukarenai ouvre son Shaarli, en remplacement de son compte StatusNet (d'après http://identi.ca/notice/98341073 -- "Annonce importante: je vais abandonner mon StatusNet très probablement en faveur d'un Shaarli. Levitatem est virtus.")
via Sebsauvage (http://sebsauvage.net/)
Pour expliquer de façon plus simple les codes erreurs de HTTP :-D
Pour les infos concrètes ensuite :
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
La version 15 du navigateur web de Mozilla Firefox, sortie aujourd'hui, intègre le codec audio Opus, comme déjà parlé ici : http://links.thican.net/?vsA4Kw
J'aimerais bien voir ce que ça donne :)
Peuh! Qu'ils sont agaçants, tous ces services pour empêcher la diffusion des épreuves olympiques sur les grands services (c-à-d monopoles) de vidéos en lignes.
Et il y a énormément d'exmples dans ce cas : http://korben.info/jeux-olympiques-mon-dieu-que-cest-sale.html