Convertisseur curl
Transformer une commande en code

Ce que fait un convertisseur curl

Une commande curl écrit une requête sous forme de ligne de commande. Ce convertisseur curl transforme cette ligne en code que vous pouvez poser dans un projet. C’est pourquoi l’en-tête copié depuis devtools garde sa valeur exacte, et vous arrêtez de le retaper.

Quatre choses reviennent d’un seul collage. D’abord la requête elle-même : méthode, adresse, en-têtes et corps, relus pour que vous puissiez les vérifier. Ensuite le code dans la langue choisie. Après cela, les interrupteurs que curl aurait appliqués, comme le suivi des redirections ou un délai. Enfin, une liste de tout ce que le lecteur a dû décider seul.

Cette dernière liste compte plus qu’elle n’en a l’air. Une supposition silencieuse dans du code généré est un bug que vous trouvez en production. Donc la page affiche chaque décision à côté du code.

Vous n’installez rien et vous n’envoyez rien. Donc vous collez une commande, vous lisez le code et vous fermez l’onglet quand cela vous arrange.

Comment un convertisseur curl lit une commande

Le travail se divise en trois passes. D’abord, la page découpe la commande en mots comme le ferait un shell. Ensuite elle lit chaque mot comme un interrupteur, une valeur ou l’adresse. Enfin elle remet la requête à un écrivain pour la langue choisie.

Le découpage suit les règles du shell pour le guillemétage, car une commande collée depuis devtools s’appuie dessus. Un corps entre guillemets simples est un seul mot même s’il contient des espaces. Une barre oblique inverse en fin de ligne la joint à la suivante.

Lire les interrupteurs est ce qui fait la valeur d’un convertisseur. Comme curl liste plus de deux cents options, seules certaines méritent d’être reprises. Celles qui comptent changent ce qu’un serveur voit. Ce sont la méthode, les en-têtes, le corps, les cookies, les redirections et le délai. La page signale le reste au lieu de le deviner.

Les écrivains ne touchent jamais au réseau. Donc la page fonctionne hors ligne. Elle fonctionne aussi sur une machine sans curl installé. Une commande peut viser une adresse que votre navigateur n’atteint pas, et la page la convertit quand même.

Pourquoi le guillemétage est la partie difficile

Un convertisseur qui coupe aux seuls espaces se trompe sur la plupart des commandes. Comme une valeur d’en-tête contient souvent un espace, un découpage naïf la coupe en deux. Alors le code porte la moitié d’un jeton et la requête échoue avec un 401.

Donc le lecteur suit l’état des guillemets pendant qu’il parcourt la ligne. Un guillemet double regroupe une suite de mots en un seul, et un guillemet simple fait de même sans aucune échappement à l’intérieur. Seul un guillemet qui ouvre et ferme aux bons endroits compte.

La barre oblique inverse est le troisième cas. Hors guillemets elle échappe le caractère suivant, et devant un saut de ligne elle supprime le saut lui-même. C’est pourquoi une commande collée sur vingt lignes se lit toujours comme une seule commande.

Quelles langues il écrit

Treize cibles couvrent le travail que presque tous apportent ici. Pour PHP il y a cURL simple et le client Guzzle. Pour Python il y a requests. Pour JavaScript il y a fetch, axios et le module http de Node.js. Go, Ruby, Java et C# en reçoivent un chacun. Puis viennent le HTTP brut, une ligne curl nettoyée et le JSON.

Chaque écrivain est une petite fonction sur le même objet de requête. À cause de cela, chaque cible voit des octets identiques. Le corps envoyé par l’exemple PHP est le corps envoyé par l’exemple Go. Rien ne rogne un en-tête par langue ni ne reformate la charge en silence.

Les écrivains PHP et Python visent du code exécutable tel quel. Donc celui de PHP ouvre avec la balise, règle les options et ferme le descripteur. Celui de Python importe requests, construit les en-têtes et affiche à la fois le statut et le corps.

JavaScript se divise en trois exprès. Fetch est livré dans le navigateur. Axios apporte ses propres commodités, et le module http de Node.js convient à un script sans dépendances. Donc les trois méritent une place.

Deux cibles servent à lire plutôt qu’à exécuter. Le HTTP brut affiche le message tel qu’il passerait sur le fil. C’est le moyen le plus rapide de voir si un en-tête est vraiment là. Le JSON affiche la même requête comme données, prête pour une fixture de test.

Ce que montre le panneau de relecture

Avant que le moindre code apparaisse, la page affiche la requête qu’elle a comprise. Neuf faits reçoivent chacun une ligne. Ils couvrent la méthode, l’adresse, le nombre d’en-têtes, la taille du corps et le type de contenu. L’autorisation, les cookies, les interrupteurs et le délai suivent.

Les adresses ne sont pas la partie intéressante. Plutôt, le point est la vérification. Un en-tête disparu apparaît ici avant que vous ne colliez quoi que ce soit. Un corps arrivé en formulaire au lieu de JSON aussi. Un mot de passe au mauvais endroit apparaît aussi.

La page affiche la liste complète des en-têtes en dessous, un par ligne. Par conséquent vous comparez ce que curl enverrait avec ce que votre serveur attend. Alors la différence est visible au lieu d’être supposée.

Le panneau nomme les interrupteurs en mots simples. Un lecteur du code ne devrait pas avoir à savoir que -L veut dire suivre les redirections. Le panneau dit follow, insecure, compressed ou silent à la place.

De devtools à un script en un collage

La voie habituelle est le navigateur. Tout grand navigateur peut copier une requête en curl. Donc ouvrez le panneau réseau, faites un clic droit sur l’appel qui a échoué, copiez-le et collez-le ici. La commande arrive avec les vrais en-têtes, le vrai corps et les vrais cookies.

C’est aussi la façon habituelle de déboguer un appel privé. Donc vous reproduisez une requête échouée en code. Puis vous ajoutez un print et regardez ce que dit le serveur, au lieu de deviner depuis un panneau réseau.

Les sauts de ligne n’ont pas d’importance. Par conséquent la page lit une commande copiée sur vingt lignes comme une seule. L’indentation non plus.