Passer une variable en post dans un href ?

[Mamat]

Je sais je suis un peu compliqué quand je m'y met ;oD, tout est dans le titre, à savoir peut-on passer une varaible dans un lien href ? J'imagine que par les sessions c'est possible... mais sinon à part ça un autre moyen ?

Merci d'avance

[Harry_20]

Oui les sessions sont très pratiques pour garder en mémoire une info et de manière plus sûre que le passage de variables par l'url !

Par rapport à ta question, il te suffit d'adopter la structure HTML - PHP :

<A href=page.php?variable="<? echo $valeur; ?>">Cliquez ici</A>

ou si le lien fait partie intégrante du code PHP :

<?

/* Insertion d'un lien HTML avec variable */

echo "<A href=\"page.php?variable=". $valeur ."\">Cliquez ici</A>";

?>

J'espère avoir répondu à ta question

[Mamat]

Merci Harry mais je code que tu me propose est basé sur la méthode GET, ce qui me pose de nombreux problème notemment pour l'encodage des caractères.

[TheRec]

Bonjour,

C'est vrai...alors utilise la fonction urlencode

Sinon pour passer des variables POST à une page depuis un lien en HTML, tu peux utiliser la fonction header ...et définir les variables et leur valeur dans les en-têtes de la page...mais j'ai un peu de peine à comprendre le but de ceci... Cela implique que tu connaisses les données au moment ou tu veux générer les en-têtes...et donc pourquoi veux tu faire comme si elles avaient été envoyées par POST...

Je comprends ce que tu veux dire par envoyer des données par POST depuis un lien en HTML, mais je ne comprends pas quelle application cela aura...

[Mamat]

Hé bien pour en dire plus c'est sur un moteur de recherche interne que je veux mettre des liens jusqu'a lors en GET pour les résultats suivants et/ou précédents, puisque j'en affiche 20 par page... c'est clair ? ;oD

[TheRec]

Tu as donc plusieurs possibilités, j'en donne deux donc une douteuse ;D

Tu utilises du Javascript pour passer à la page suivant ou précédente qui soumet le formulaire de recherche avec un champ caché qui change de valeur en fonction du lien cliqué... Très mauvais solution au niveau de l'accessibilité. Je te la déconseille...

Ou tu fais "comme tout le monde", tu utilises le GET pour passer les mots-clés ainsi que l'offset (la page) à afficher... les mots-clés doivent être encodés avec la fonction que j'ai cité précédemment : urlencode ou rawurlencode (cette dernière n'a aucune exception, alors que la première encode les espace en "+" au lieu de %20...cette différence à des raisons historiques liées à l'utilisation des formulaires)

Tu n'auras aucun problème, elle convertit tous les caractères qui n'ont pas leur place en tant que tels dans l'URL en leur entité ...par exemple un espace devient %20 ...un slash %2F ... etc. (cela correspond à la valeur hexadécimale du code ASCII du caractère en question précédé du caractère % qui indique que c'est un caractère encodé qui suit...)

[Anonymus]

Pour info, c'est la méthode utilisée par tous les moteurs de recherche

Regarde bien leur url, lorsque tu changes de page

[oscarine]

Normalement POST est utilisé par des requêtes qui sont susceptibles de modifier le contenu du serveur distant (par exemple s'inscrire au forum, poster un message, commander une pizza...).

GET c'est pour les requêtes qui ne modifient pas l'état du serveur. Exemple une recherche, bien qu'utilisant un formulaire devrait en général utiliser GET. L'envoi à une autre page devrait aussi être un GET.

C'est pas seulement pour couper les cheveux en quatre mais par exemple les caches en général 'cachent' les requêtes GET mais pas les POST.

[Mamat]

Je sais tout ça et c'est ce que je faisais jusque là, mais j'ai des soucis aves le apostrophes, il me les encode bien puis dans le lien page suivante il me met un antislash devant le %27 (l'apostrophe) en plus il faut que je les décode, mais avec koi ? je ne suis pas sur mais peut-etre htmlentities ?

[TheRec]

Avec urldecode ou rawurldecode (en fonction de ce que tu as utilisé pour encoder)...

P.S. : Si tu avais visité et lu le manuel PHP pour urlencode, tu aurais eu la réponse.

[Mamat]

Arf évidemment.... ;oD

[xorax]

à propos de la méthode d'envoi GET, quel sont les limites d'envoi des données maintenant en fonctions des navigateur ??

Parce que je trouve que c'est le gros désavantage de la métode GET contrairement à POST qui n'est pas limité (ou presque sauf par les directives serveur).

[Anonymus]

Aucune, tu peux envoyer beaucoup de données, par méthode GET. Mais elle n'est pas faite pour ca.

[xorax]

je vien de tester, alor autant je suis d'accord de la réponse pour firefox et opera (jarive à plus plus de 4000 caractère) mais pour IE ça semble être limité à 2048 voir moin...

Le problème c'est qu'on à parfoit besoin de plus dans le cas par exemple d'envoie de donné crypté à paypal, on ne peut que faire une redirection http ou alor par l'envoie de formulaire en POST mais qui implique un javascript pour que la redirection soit presque transparente et donc pas vraiment fiable.

[TheRec]

Effectivement, la longueur des URL sous IE est limitée à 2083 caractères. Je suppose que cela correspond à une interprétation erronée de la RFC des développeurs :

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Cela implique donc que la gestion de la longueur d'URL devrait se faire côté serveur et que le client lui ne devrait pas limiter sa longueur. Maintenant, peut-être qu'ils considèrent cela comme une "mesure de sécurité"...en tous les cas ils ont tort

Firefox as une limite beaucoup plus raisonnable : 65635 caractères (en tout cas dans version 1.5.0.2)...

Toutefois l'utilisation d'URL longues n'est pas vraiment conseillée en général, pour des raisons diverses (impossibilité de les mémoriser humainement, difficultés pour communiquer les URL à d'autres personnes, ...). J'ai bien compris que le système que tu veux mettre en place n'est pas vraiment du type à devoir être facilement mémorisable (carte de crédit), mais tu va te heurter à un mur si tu utilise des URL trop longues, IE7 Beta2 ne gère plus que 2047 caractères (d'après ce que j'ai pu voir, mais ce n'est qu'une Beta). HTTP a ses limites...mais dans ce cas c'est les navigateurs (ne montrons pas du doigt IE) qui les reculent encore plus

[xorax]

ralala... moi qui pensait qu'ils feraient moin les bouffons avec IE7...

personne à jamais fait de virus pour bannir IE de tout système??

EDIT : je sui bète, ce serait pas un virus

Modifié 24 Avril 2006 par xorax

[Anonymus]

Les bouffons sont ceux qui utilisent GET pour l'envoi d'informations comme celles-ci. J'ai actuellement le cas d'envoi d'un xml (assez long..) en GET.

Il existe quantité de méthodes pour envoyer des informations longues, et GET est probablement la pire. Limiter la longueur est normale, de toute facon ca n'est pas fait pour ca.

Mais de manière générale : Si tu as besoin d'envoyer des infos en GET, en revanche ca ne transite pas forcément par le navigateur du client. Donc, tu n'es pas forcément limité par la longueur..

Perso, je suis dans le cas d'envoi d'un xml en GET, et ca passe sans problèmes. L'envoi se fait coté serveur (et non client IE).

[xorax]

je ne suis pas responsable des systèmes que je n'administre pas et je fais comme tout le monde, je me plie aux contraintessss.

Si je pouvais faire une redirection transparente avec un envoie en post compatible chez tout le monde je le ferais, mais d'après se que j'ai lu c'est au-dela des limites du http.

Et dans le cas de paiement sécurisé, je vois mal comment redirigé coté serveur à part mettre en place un système de socket qui finirait par faire perdre toute confiance au client en la transaction.

Mais si quelqu'un à un exemple de redirection client (obligatoire ici) transparente multicompatibilite avec des variables de taille non limité (variable obligatoire et non fichier), je suis preneur.