Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit
un élément dans la liste. L'Url devient :
http://www.monsite.com/viewbook.php?nombook=mon-select
Alors que je voudrais
http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Le but étant d'effectuer une deuxième requête qui permettra de visualiser le
contenu d'une rubrique dans un livre.
$where = 'WHERE intNumBook='.$numbook.' AND txtNomBook='.$nombook;
Par avance, merci de votre aide et de vos réponses.
"Batiboy" a écrit dans le message de news:441d074c$0$20270$
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit
un élément dans la liste. L'Url devient : http://www.monsite.com/viewbook.php?nombook=mon-select Alors que je voudrais http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete Le but étant d'effectuer une deuxième requête qui permettra de visualiser le
contenu d'une rubrique dans un livre.
il f aut ajouter dans la form un champ de type hidden (donc qui n'apparait pas à l'écran) pour chaque parametre que l'on désire passer avec la form ( input type=hidden name=numbook value=$numbook)
"Batiboy" <tpmsn2004nospam@freenospam.fr> a écrit dans le message de
news:441d074c$0$20270$626a54ce@news.free.fr...
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir
choisit
un élément dans la liste. L'Url devient :
http://www.monsite.com/viewbook.php?nombook=mon-select
Alors que je voudrais
http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Le but étant d'effectuer une deuxième requête qui permettra de visualiser
le
contenu d'une rubrique dans un livre.
il f aut ajouter dans la form un champ de type hidden (donc qui n'apparait
pas à l'écran) pour chaque parametre que l'on désire passer avec la form
( input type=hidden name=numbook value=$numbook)
"Batiboy" a écrit dans le message de news:441d074c$0$20270$
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit
un élément dans la liste. L'Url devient : http://www.monsite.com/viewbook.php?nombook=mon-select Alors que je voudrais http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete Le but étant d'effectuer une deuxième requête qui permettra de visualiser le
contenu d'une rubrique dans un livre.
il f aut ajouter dans la form un champ de type hidden (donc qui n'apparait pas à l'écran) pour chaque parametre que l'on désire passer avec la form ( input type=hidden name=numbook value=$numbook)
Frederic Rouchouze
echo '<form>';
Déjà, je te conseille d'utiliser la méthode "POST" plutôt que "GET" (par défaut) : echo '<form method="post">
Il faut que tu fasses passer ton paramètre NumBook à la page appelée par le formulaire. Pour cela, tu peux ajouter un champ <input type="hidden"> à ton formulaire : echo '</select>'; echo '<input type="hidden" name="numbook" value="'.$numbook.'">'; echo '<input type="submit" value="Voir">'; echo '</form>';
-- Frédéric Rouchouze mailto:
echo '<form>';
Déjà, je te conseille d'utiliser la méthode "POST" plutôt que "GET" (par
défaut) :
echo '<form method="post">
Il faut que tu fasses passer ton paramètre NumBook à la page appelée par le
formulaire. Pour cela, tu peux ajouter un champ <input type="hidden"> à ton
formulaire :
echo '</select>';
echo '<input type="hidden" name="numbook" value="'.$numbook.'">';
echo '<input type="submit" value="Voir">';
echo '</form>';
Il faut que tu fasses passer ton paramètre NumBook à la page appelée par le formulaire. Pour cela, tu peux ajouter un champ <input type="hidden"> à ton formulaire : echo '</select>'; echo '<input type="hidden" name="numbook" value="'.$numbook.'">'; echo '<input type="submit" value="Voir">'; echo '</form>';
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit un élément dans la liste. L'Url devient : http://www.monsite.com/viewbook.php?nombook=mon-select Alors que je voudrais http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Comment veux-tu que la variable $numbook soit envoyée si elle n'est pas spécifiée dans le formulaire ?
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit
un élément dans la liste. L'Url devient :
http://www.monsite.com/viewbook.php?nombook=mon-select
Alors que je voudrais
http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Comment veux-tu que la variable $numbook soit envoyée si elle n'est pas
spécifiée dans le formulaire ?
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit un élément dans la liste. L'Url devient : http://www.monsite.com/viewbook.php?nombook=mon-select Alors que je voudrais http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Comment veux-tu que la variable $numbook soit envoyée si elle n'est pas spécifiée dans le formulaire ?
Bruno Desthuilliers
Bonjour à tous,
Débutant, je tourne en rond, et je n'arrive pas à trouver une réponse à mon problème. Mon problème : Je clique sur un lien :
qui ouvre une page php dans laquelle une liste est remplie suivant le critère intNumBook
<hs> La notation polonaise est une horreur. Economise toi de la frappe clavier, "$numbook" est assez parlant comme ça. </hs>
<?php $numbook = $_GET['numbook'];
n'utilise *jamais* ce qui arrive de l'extérieur sans vérification et nettoyage préalable - à moins que tu ne tiennes à ce que tous les apprentis pirates viennent faire mumuse sur ton serveur.
echo '<img src="_imagesbook'
pourquoi un antislash ??? Et pourquoi un underscore ???
$result = mysql_query($request) or die('Erreur '.mysql_errno().' :<br>Erreur lors de l´exécution de la requête<br><code>'.$request.'</code><br><b>'.mysql_error()).'</b>';
Ce message d'erreur n'est pas destiné à l'utilisateur, mais au développeur ou à l'admin. Logue le (il y a une fonction pour ça) et retourne à l'utilisateur un message d'excuse (ie "Désolé, votre requête n'a pu aboutir. Si le problème persiste etc...")
$arrViewBook = $result;
si "arr" est pour array, il y a erreur (ah, les joies de la notation polonaise... c'est encore plus efficace quand c'est erroné). Ce que te renvoie la requête est une "resource" (voire le Fameux Manuel - en bref, c'est un identifiant système qui sera utilisé pour récupérer le résultat de la requête).
Accessoirement, tu dois aussi tester si mysql_query() t'a bien retourné une ressource *valide*. Sinon, c'est le fetch qui va partir en vrille.
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit un élément dans la liste. L'Url devient : http://www.monsite.com/viewbook.php?nombook=mon-select
C'est normal.
Alors que je voudrais http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Il faut le mettre dans le formulaire (dans un input hidden). HTTP est un protocole sans état, donc chaque requête doit contenir toutes les informations nécessaires.
Petits conseils: 1/ sépare autant que possible les traitements du rendu. Ici par exemple, commence par faire ta requête etc, et ne commence la génération du HTML qu'après. 2/ avant de construire ton formulaire, regarde combien de résultats ta requête retourne (il y a une API pour ça, mysql_count_rows() ou quelque chose comme ça...). S'il y a moins de deux résultat, pas la peine de proposer un select (s'il n'y en a qu'un, tu peux tout de suite afficher le résultat complet, et s'il n'y en a pas un message d'erreur).
Et *surtout*, n'utilise *jamais* ce qui vient de l'extérieur sans vérification et nettoyage préalable. Telle que ta requête est construite, il est très facile d'injecter un insert ou un delete dedans.
Mes deux centimes...
Bonjour à tous,
Débutant, je tourne en rond, et je n'arrive pas à trouver une réponse à mon
problème.
Mon problème :
Je clique sur un lien :
qui ouvre une page php dans laquelle une liste est remplie suivant le
critère intNumBook
<hs>
La notation polonaise est une horreur. Economise toi de la frappe
clavier, "$numbook" est assez parlant comme ça.
</hs>
<?php
$numbook = $_GET['numbook'];
n'utilise *jamais* ce qui arrive de l'extérieur sans vérification et
nettoyage préalable - à moins que tu ne tiennes à ce que tous les
apprentis pirates viennent faire mumuse sur ton serveur.
echo '<img src="_imagesbook'
pourquoi un antislash ??? Et pourquoi un underscore ???
$result = mysql_query($request) or die('Erreur '.mysql_errno().'
:<br>Erreur lors de l´exécution de la
requête<br><code>'.$request.'</code><br><b>'.mysql_error()).'</b>';
Ce message d'erreur n'est pas destiné à l'utilisateur, mais au
développeur ou à l'admin. Logue le (il y a une fonction pour ça) et
retourne à l'utilisateur un message d'excuse (ie "Désolé, votre requête
n'a pu aboutir. Si le problème persiste etc...")
$arrViewBook = $result;
si "arr" est pour array, il y a erreur (ah, les joies de la notation
polonaise... c'est encore plus efficace quand c'est erroné). Ce que te
renvoie la requête est une "resource" (voire le Fameux Manuel - en bref,
c'est un identifiant système qui sera utilisé pour récupérer le résultat
de la requête).
Accessoirement, tu dois aussi tester si mysql_query() t'a bien retourné
une ressource *valide*. Sinon, c'est le fetch qui va partir en vrille.
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit
un élément dans la liste. L'Url devient :
http://www.monsite.com/viewbook.php?nombook=mon-select
C'est normal.
Alors que je voudrais
http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Il faut le mettre dans le formulaire (dans un input hidden). HTTP est un
protocole sans état, donc chaque requête doit contenir toutes les
informations nécessaires.
Petits conseils:
1/ sépare autant que possible les traitements du rendu. Ici par exemple,
commence par faire ta requête etc, et ne commence la génération du HTML
qu'après.
2/ avant de construire ton formulaire, regarde combien de résultats ta
requête retourne (il y a une API pour ça, mysql_count_rows() ou quelque
chose comme ça...). S'il y a moins de deux résultat, pas la peine de
proposer un select (s'il n'y en a qu'un, tu peux tout de suite afficher
le résultat complet, et s'il n'y en a pas un message d'erreur).
Et *surtout*, n'utilise *jamais* ce qui vient de l'extérieur sans
vérification et nettoyage préalable. Telle que ta requête est
construite, il est très facile d'injecter un insert ou un delete dedans.
qui ouvre une page php dans laquelle une liste est remplie suivant le critère intNumBook
<hs> La notation polonaise est une horreur. Economise toi de la frappe clavier, "$numbook" est assez parlant comme ça. </hs>
<?php $numbook = $_GET['numbook'];
n'utilise *jamais* ce qui arrive de l'extérieur sans vérification et nettoyage préalable - à moins que tu ne tiennes à ce que tous les apprentis pirates viennent faire mumuse sur ton serveur.
echo '<img src="_imagesbook'
pourquoi un antislash ??? Et pourquoi un underscore ???
$result = mysql_query($request) or die('Erreur '.mysql_errno().' :<br>Erreur lors de l´exécution de la requête<br><code>'.$request.'</code><br><b>'.mysql_error()).'</b>';
Ce message d'erreur n'est pas destiné à l'utilisateur, mais au développeur ou à l'admin. Logue le (il y a une fonction pour ça) et retourne à l'utilisateur un message d'excuse (ie "Désolé, votre requête n'a pu aboutir. Si le problème persiste etc...")
$arrViewBook = $result;
si "arr" est pour array, il y a erreur (ah, les joies de la notation polonaise... c'est encore plus efficace quand c'est erroné). Ce que te renvoie la requête est une "resource" (voire le Fameux Manuel - en bref, c'est un identifiant système qui sera utilisé pour récupérer le résultat de la requête).
Accessoirement, tu dois aussi tester si mysql_query() t'a bien retourné une ressource *valide*. Sinon, c'est le fetch qui va partir en vrille.
Mon problème est lorsque je clique sur le bouton 'Voir' après avoir choisit un élément dans la liste. L'Url devient : http://www.monsite.com/viewbook.php?nombook=mon-select
C'est normal.
Alors que je voudrais http://www.monsite.com/viewbook.php?nombook=mon-select&numbook=ma-requete
Il faut le mettre dans le formulaire (dans un input hidden). HTTP est un protocole sans état, donc chaque requête doit contenir toutes les informations nécessaires.
Petits conseils: 1/ sépare autant que possible les traitements du rendu. Ici par exemple, commence par faire ta requête etc, et ne commence la génération du HTML qu'après. 2/ avant de construire ton formulaire, regarde combien de résultats ta requête retourne (il y a une API pour ça, mysql_count_rows() ou quelque chose comme ça...). S'il y a moins de deux résultat, pas la peine de proposer un select (s'il n'y en a qu'un, tu peux tout de suite afficher le résultat complet, et s'il n'y en a pas un message d'erreur).
Et *surtout*, n'utilise *jamais* ce qui vient de l'extérieur sans vérification et nettoyage préalable. Telle que ta requête est construite, il est très facile d'injecter un insert ou un delete dedans.
Mes deux centimes...
Bruno Desthuilliers
echo '<form>';
Déjà, je te conseille d'utiliser la méthode "POST" plutôt que "GET" (par défaut) :
Pas dans ce cas. Le formulaire a pour but de construire l'URL complète vers une ressource donnée, donc la méthode appropriée est bien GET.
<op> En bref (tu peux lire la doc du protocole HTTP pour plus de précisions): - GET est pour obtenir une ressource - directement, ou via un formulaire de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une page... - POST est pour soumettre des données au serveur pour traitement (ie: envoi de mail, mise à jour d'une base de données, upload de fichers etc). </op>
echo '<form>';
Déjà, je te conseille d'utiliser la méthode "POST" plutôt que "GET" (par
défaut) :
Pas dans ce cas. Le formulaire a pour but de construire l'URL complète
vers une ressource donnée, donc la méthode appropriée est bien GET.
<op>
En bref (tu peux lire la doc du protocole HTTP pour plus de précisions):
- GET est pour obtenir une ressource - directement, ou via un formulaire
de recherche. C'est la méthode qu'emploie ton navigateur pour afficher
une page...
- POST est pour soumettre des données au serveur pour traitement (ie:
envoi de mail, mise à jour d'une base de données, upload de fichers etc).
</op>
Déjà, je te conseille d'utiliser la méthode "POST" plutôt que "GET" (par défaut) :
Pas dans ce cas. Le formulaire a pour but de construire l'URL complète vers une ressource donnée, donc la méthode appropriée est bien GET.
<op> En bref (tu peux lire la doc du protocole HTTP pour plus de précisions): - GET est pour obtenir une ressource - directement, ou via un formulaire de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une page... - POST est pour soumettre des données au serveur pour traitement (ie: envoi de mail, mise à jour d'une base de données, upload de fichers etc). </op>
Frederic Rouchouze
<op> En bref (tu peux lire la doc du protocole HTTP pour plus de précisions): - GET est pour obtenir une ressource - directement, ou via un formulaire de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une page... - POST est pour soumettre des données au serveur pour traitement (ie: envoi de mail, mise à jour d'une base de données, upload de fichers etc). </op>
OK. Merci de la précision. En effet, la méthode GET a l'air plus appropriée dans ce cas-là.
Mais, hormi ces considérations "philosophiques", y a-t-il des différences importantes entre ces deux méthodes ? (performances, sécurité, portabilité, etc.)
Merci, -- Frédéric Rouchouze mailto:
<op>
En bref (tu peux lire la doc du protocole HTTP pour plus de précisions):
- GET est pour obtenir une ressource - directement, ou via un formulaire
de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une
page...
- POST est pour soumettre des données au serveur pour traitement (ie:
envoi de mail, mise à jour d'une base de données, upload de fichers etc).
</op>
OK. Merci de la précision. En effet, la méthode GET a l'air plus appropriée
dans ce cas-là.
Mais, hormi ces considérations "philosophiques", y a-t-il des différences
importantes entre ces deux méthodes ? (performances, sécurité, portabilité,
etc.)
<op> En bref (tu peux lire la doc du protocole HTTP pour plus de précisions): - GET est pour obtenir une ressource - directement, ou via un formulaire de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une page... - POST est pour soumettre des données au serveur pour traitement (ie: envoi de mail, mise à jour d'une base de données, upload de fichers etc). </op>
OK. Merci de la précision. En effet, la méthode GET a l'air plus appropriée dans ce cas-là.
Mais, hormi ces considérations "philosophiques", y a-t-il des différences importantes entre ces deux méthodes ? (performances, sécurité, portabilité, etc.)
Merci, -- Frédéric Rouchouze mailto:
Bruno Desthuilliers
<op> En bref (tu peux lire la doc du protocole HTTP pour plus de précisions): - GET est pour obtenir une ressource - directement, ou via un formulaire de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une page... - POST est pour soumettre des données au serveur pour traitement (ie: envoi de mail, mise à jour d'une base de données, upload de fichers etc). </op>
OK. Merci de la précision. En effet, la méthode GET a l'air plus appropriée dans ce cas-là.
Mais, hormi ces considérations "philosophiques",
Ce n'est pas "philosophique". HTTP est un protocole (ie : un langage), il conviendrait donc de respecter sa syntaxe et sa sémantique. Même si cette sémantique laisse place à une bonne part d'interprétation.
y a-t-il des différences importantes entre ces deux méthodes ? (performances, sécurité, portabilité, etc.)
D'un point de vue purement technique, la principale différence est que, dans une requête GET, toute la requête est codée dans l'url, et qu'une url pouvant être limitée en taille (soit par le serveur, soit par le client, soit par un proxy),
Du point de vue de l'utilisateur, il y a deux différences notables:
1/ l'intégralité des arguments d'une requête GET est dans l'url. On peut donc bookmarker cette url.
2/ dans la mesure où on peut la bookmarquer, on ne s'attend pas à ce que le fait de faire un nouveau GET ait des effets de bords tels qu'envoi de mail ou insertion/mise à jour de données.
Merci,
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
<op>
En bref (tu peux lire la doc du protocole HTTP pour plus de précisions):
- GET est pour obtenir une ressource - directement, ou via un formulaire
de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une
page...
- POST est pour soumettre des données au serveur pour traitement (ie:
envoi de mail, mise à jour d'une base de données, upload de fichers etc).
</op>
OK. Merci de la précision. En effet, la méthode GET a l'air plus appropriée
dans ce cas-là.
Mais, hormi ces considérations "philosophiques",
Ce n'est pas "philosophique". HTTP est un protocole (ie : un langage),
il conviendrait donc de respecter sa syntaxe et sa sémantique. Même si
cette sémantique laisse place à une bonne part d'interprétation.
y a-t-il des différences
importantes entre ces deux méthodes ? (performances, sécurité, portabilité,
etc.)
D'un point de vue purement technique, la principale différence est que,
dans une requête GET, toute la requête est codée dans l'url, et qu'une
url pouvant être limitée en taille (soit par le serveur, soit par le
client, soit par un proxy),
Du point de vue de l'utilisateur, il y a deux différences notables:
1/ l'intégralité des arguments d'une requête GET est dans l'url. On peut
donc bookmarker cette url.
2/ dans la mesure où on peut la bookmarquer, on ne s'attend pas à ce que
le fait de faire un nouveau GET ait des effets de bords tels qu'envoi de
mail ou insertion/mise à jour de données.
Merci,
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
<op> En bref (tu peux lire la doc du protocole HTTP pour plus de précisions): - GET est pour obtenir une ressource - directement, ou via un formulaire de recherche. C'est la méthode qu'emploie ton navigateur pour afficher une page... - POST est pour soumettre des données au serveur pour traitement (ie: envoi de mail, mise à jour d'une base de données, upload de fichers etc). </op>
OK. Merci de la précision. En effet, la méthode GET a l'air plus appropriée dans ce cas-là.
Mais, hormi ces considérations "philosophiques",
Ce n'est pas "philosophique". HTTP est un protocole (ie : un langage), il conviendrait donc de respecter sa syntaxe et sa sémantique. Même si cette sémantique laisse place à une bonne part d'interprétation.
y a-t-il des différences importantes entre ces deux méthodes ? (performances, sécurité, portabilité, etc.)
D'un point de vue purement technique, la principale différence est que, dans une requête GET, toute la requête est codée dans l'url, et qu'une url pouvant être limitée en taille (soit par le serveur, soit par le client, soit par un proxy),
Du point de vue de l'utilisateur, il y a deux différences notables:
1/ l'intégralité des arguments d'une requête GET est dans l'url. On peut donc bookmarker cette url.
2/ dans la mesure où on peut la bookmarquer, on ne s'attend pas à ce que le fait de faire un nouveau GET ait des effets de bords tels qu'envoi de mail ou insertion/mise à jour de données.
Merci,
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Frederic Rouchouze
1/ l'intégralité des arguments d'une requête GET est dans l'url. On peut donc bookmarker cette url. 2/ dans la mesure où on peut la bookmarquer, on ne s'attend pas à ce que le fait de faire un nouveau GET ait des effets de bords tels qu'envoi de mail ou insertion/mise à jour de données.
Merci pour ces infos. C'est tout à fait la réponse que j'attendais !
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Oui je sais mais bon... mais comme je trouve ça assez indigeste, je préfère la solution de facilité ! (J'ai vainement essayé de comprendre la différence entre URL et URI en lisant les RFC et j'ai rien compris ! Ensuite je suis allé sur des sites persos et c'est devenu plus clair tout à coup...) -- Frédéric Rouchouze mailto:
1/ l'intégralité des arguments d'une requête GET est dans l'url. On peut
donc bookmarker cette url.
2/ dans la mesure où on peut la bookmarquer, on ne s'attend pas à ce que
le fait de faire un nouveau GET ait des effets de bords tels qu'envoi de
mail ou insertion/mise à jour de données.
Merci pour ces infos. C'est tout à fait la réponse que j'attendais !
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Oui je sais mais bon... mais comme je trouve ça assez indigeste, je préfère
la solution de facilité !
(J'ai vainement essayé de comprendre la différence entre URL et URI en
lisant les RFC et j'ai rien compris ! Ensuite je suis allé sur des sites
persos et c'est devenu plus clair tout à coup...)
--
Frédéric Rouchouze
mailto:fredchou@nospam.free.fr
1/ l'intégralité des arguments d'une requête GET est dans l'url. On peut donc bookmarker cette url. 2/ dans la mesure où on peut la bookmarquer, on ne s'attend pas à ce que le fait de faire un nouveau GET ait des effets de bords tels qu'envoi de mail ou insertion/mise à jour de données.
Merci pour ces infos. C'est tout à fait la réponse que j'attendais !
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Oui je sais mais bon... mais comme je trouve ça assez indigeste, je préfère la solution de facilité ! (J'ai vainement essayé de comprendre la différence entre URL et URI en lisant les RFC et j'ai rien compris ! Ensuite je suis allé sur des sites persos et c'est devenu plus clair tout à coup...) -- Frédéric Rouchouze mailto:
bruno at modulix
Frederic Rouchouze wrote: (snip)
Merci pour ces infos. C'est tout à fait la réponse que j'attendais !
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Oui je sais mais bon... mais comme je trouve ça assez indigeste, je préfère la solution de facilité !
Qui est de laisser à d'autre le soin de les prédigérer pour toi ?-)
Ok, les rfc sont, effectivement, assez peu digestes en général - comme toute specification technique d'ailleurs (tu a déjà essayé de lire la norme du langage C ? Et encore, c'est une des plus simples...). Mais bon, faire du développement web sans connaitre un minimum les specs du protocole HTTP, ça me semble quand même assez surréaliste.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Frederic Rouchouze wrote:
(snip)
Merci pour ces infos. C'est tout à fait la réponse que j'attendais !
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Oui je sais mais bon... mais comme je trouve ça assez indigeste, je préfère
la solution de facilité !
Qui est de laisser à d'autre le soin de les prédigérer pour toi ?-)
Ok, les rfc sont, effectivement, assez peu digestes en général - comme
toute specification technique d'ailleurs (tu a déjà essayé de lire la
norme du langage C ? Et encore, c'est une des plus simples...). Mais
bon, faire du développement web sans connaitre un minimum les specs du
protocole HTTP, ça me semble quand même assez surréaliste.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Merci pour ces infos. C'est tout à fait la réponse que j'attendais !
De rien. Au fait, tu sais que les rfc sont disponibles sur le net ?
Oui je sais mais bon... mais comme je trouve ça assez indigeste, je préfère la solution de facilité !
Qui est de laisser à d'autre le soin de les prédigérer pour toi ?-)
Ok, les rfc sont, effectivement, assez peu digestes en général - comme toute specification technique d'ailleurs (tu a déjà essayé de lire la norme du langage C ? Et encore, c'est une des plus simples...). Mais bon, faire du développement web sans connaitre un minimum les specs du protocole HTTP, ça me semble quand même assez surréaliste.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"