Lanza

Bonsoir,

Sans vouloir casser l'ambiance, tu as une sacrée concurrence. Je ne suis pas certain que les recettes de cuisine soient le marché le plus facile à conquérir aujourd'hui.

En quoi un OS Linux est-il plus performant qu'un autre pour du contrôle à distance ?

La fenêtre de commande de Windows est un poil merdique, dès qu'on s'amuse un peu avec SSH. Pour du TSE, ou une interface web, c'est kif kif.

Ensuite ça dépend de l'environnement de travail, les langages et logiciels utilisés. Faire de l'ASP.Net sous Linux relève plus du masochisme qu'autre chose, par exemple.

Personnellement, je suis sous Linux (Ubuntu) depuis 6 mois et je ne m'en plains pas, mais je vais probablement passer sur Mac dans pas longtemps, pour éviter de me prendre la tête avec la config des machines. Une quand on est tout seul, ça va, mais à partir du moment où il y en a plusieurs, les problèmes de drivers et compagnie peuvent rapidement devenir chronophages. A moins de prendre des machines Linux toutes prêtes chez un revendeur.

Bonsoir,

"imap_headerinfo", c'est pour le protocole IMAP pas POP, donc ça risque effectivement de ne pas bien marcher

Un conseil de bon sens : toujours prévenir le visiteur quand on ouvre une nouvelle fenêtre.

Je fais partie des utilisateurs dont parle Monique, qui ont l'habitude de gérer leurs onglets et qui ne supportent pas qu'on leur force la main. Mais si on me prévient avant, je suis plus conciliant

Passer de l'environnement de développement à un hébergement OVH

Comment configurer mon environnement de développement pour que le déploiement se fasse le plus simplement possible ?

Si tu as un accès SSH à ton hébergement, que tu as la bonne habitude d'utiliser un système de contrôle de sources (CVS ou Subversion), et que tu n'as rien contre ruby, tu peux jeter un oeil à Capistrano. C'est prévu pour Ruby on Rails à la base, mais rien n'empêche de s'en servir avec un autre type d'application. Ça permet d'automatiser le déploiement, de revenir en arrière quand on a fait une boulette, le tout en une seule commande.

Il y a toujours la possibilité de la négociation de contenu : regarder les en-têtes HTTP pour connaître la langue préférée envoyée par le navigateur et rediriger en conséquence. fr-FR -> france, fr-BE -> belgique, etc.

Si l'entête n'est pas envoyé, ou ne correpond à aucune des options, envoyer la page qui permet le choix.

possible ... je ne connais pas grand chose .

en tous cas les liens de mon site pointent vers des adresses simples comme celle en verte.

Comment je fais pour interdire google de faire ces inventions ?

Google n'invente rien, si ces adresses sont indexées, c'est qu'ils les a trouvées dans un lien.

Si tu désactives les cookies dans ton navigateur, tu devrais voir apparaître le PHPSESSIONID. Je suppose qu'en changeant d'autres paramètres, et en parcourant un peu le site pas forcément par le menu principal, on doit pouvoir retrouver les autres paramètres amusants qui sont rajoutés (comme le flash=non en désactivant flash). C'est le script de ton site qui est en cause, et il va falloir le modifier (il est possible que ce soit de grosses modifs) si tu veux vraiment faire disparaître ces url.

En théorie, une session ne devrait jamais être initiée par un lien (methode HTTP GET), mais uniquement après un POST (de formulaire). Comme les robots ne suivent pas les POST le PHPSESSIONID n'apparaît pas, si cette règle était respectée.

Merci.

Heu le coup du Frameset..t'es sur ??

Oui

Bénon puisque l'autre renverra une erreur 404, donc devrait se faire virer de l'index.

Et d'ailleurs, si le titre change, il y a fort à parier que le contenu aura suffisamment changé lui aussi pour éviter le duplicate content.

L'idée est d'interdire les referrers qui n'appartiennent pas au domaine.

Yapluka chercher dans la doc d'Apache comment on fait

Attention toutefois, certaines configurations utilisateurs trop "sécurisées" n'envoient pas le referrer, (merci Norton Internet Security et consorts), ce qui fait que les gens avec ce genre de configuration ne verront pas tes images.

Ah heuuuu.... houlà.

Pour stocker et faire fonctionner le site ou juste pour la saisie ?

Si c'est pour stocker, oublier Excel. (Les mauvaises langues rajouteront File Maker Pro et Access également.)

Ensuite, le serveur du site tourne utilise quel système d'exploitation ? Si c'est un serveur Linux, difficultés en perspective pour lire ces fichiers.

Ces trois logiciels sont adaptés à une utilisation bureautique, pas à une utilisation en tant que système de base de données pour le Web, même si Access est parfois utilisé comme tel. En général on utilise MySQL, ou SQLite (pour les petites bases) sur des serveurs Linux, et SQLServer sur des serveurs Windows.

Si la liste des contacts est le seul contenu en base de données et que le serveur est un serveur windows, Access peut faire l'affaire.

JE crois que le contrôle parental est activé par défaut, mais il faudrait vérifier, je n'ai pas AOL. Mais en fait à la relecture, si ça te sert le 404 personnalisé, ça ne doit pas être un problème de contrôle parental, ni de timeout.

Il y a quelque chose de pas net ailleurs, probablement dans la requête du navigateur AOL.

Sinon la page d'accueil est en XHTML Frameset, alors qu'elle devrait être en transitional, si j'en crois le code.

Normalement c'est juste pour les Frames (pas les iframes, les frames), body est interdit dans un document XHTML Frameset. . On pourrait imaginer, même si je vois mal pourquoi que le navigateur AOL essaie d'afficher des Frames en allant piocher une adresse je ne sais où d'où le 404. Mais c'est chercher loin ??

La première chose que je ferais c'est de regarder dans le logs du serveurs les requêtes passées via AOL, et regarder l'url qui est demandée.

Quelques pistes :

- L'encodage des caractères. Est-ce que le nav d'AOL ferait pas des trucs bizarres ?

- Le site est lent (oui, déslé, une dizaine de secondes pour s'afficher ici), voir si y'a pas un délai max dans le navigateur AOL avant que ça ne décroche

- Chercher du côté de mots qui ne passeraient pas le contrôle parental ?

Dans mon script.....franchement je suis perdu là.

Tout ce que je sais faire c' est du html moi !

Ah....admin du serveur....j' en sais rien, mais c' est moi qui m' occuperai de la gestion des fichiers html, css etc.... c' est ce dont tu parlais ?

M'est avis qu'on te complique la tâche, juste pour le plaisir de causer.

Ce qu'on veut dire avec la sensibilité à la casse c'est que :

http://www.tonsite.com/toto.html

et

http://www.tonsite.com/TOTO.HTML

sur un serveur Windows, c'est la même page, alors que sur un serveur Linux ce sont deux pages différentes. Il faut juste faire gaffe quand on fait des liens.

Et administrateur du serveur, ça signifie que tu gères la machine sur laquelle tourne ton site (installation des logiciels, mise à jour, etc). Ce qui je pense, n'est pas ton cas, c'est 1&1 qui s'en occupe.

Et moi qui espérais naïvement trouver une réponse simple !

Merci à tous pour vos interventions. J'avoue que j'ai, du coup, du mal à y voir clair... Connaissez-vous des exemples de sites qui, à vos yeux, ont magistralement réglé cette question ? (j'entends par là des sites chargés en contenus, contraints de gérer proprement leurs pages d'archives)

Les moteurs de blog, par exemple, qui stockent leurs url sous la forme /annee/mois/jour/titre ou titre tout court, en laissant l'utilisateur corriger en cas de doublon.

Toute fois, davidm soulève un point intéressant : peut-être qu'il s'agit de beaucoup de complications pour quelque chose qui arrive peu (à savoir changer le titre d'un article).

Et rien n'empêche de garder l'ancien titre comme id. Cool URLs don't change

Ok merci à vous.

Je viens de me rendre compte que l' offre n' est pas la même selon windows ou linux. L' offre Windows qui est plus cher ne supporte pas mysql.

Donc, c' est réglé vu que je dois mettre un forum qui necessite mysql ( phpbb ) je vais choisir l' offre linux et en plus c' est moins cher.

Concernant cette histoire de majuscules, tu disais :

[...]

et sinon oui, je serai l' admin du site.

Admin du site ou du serveur ? Ce n'est pas la même chose

Pour du PHP/MySQL, je confirme, un hébergement LAMP (Linux Apache MySQL PHP) est le plus indiqué.

Pour finir, il est tout à fait possible d'utiliser MySQL sur un hébergement Windows.

Sauf dans l'offre 1&1, ça n'est pas proposé.

Salut Karnabal, entièrement d'accord avec toi pour le fond.

Mais sur la forme, ton exemple est parfaitement faux: ce n'est pas à cause de l'IP, Google n'interdit donc rien du simple fait de l'IP, et donc ce n'est pas du tout semblable à ce que abille nous expose.

Puisque la redirection google.com vers google.fr se fait uniquement à cause d'un cookie. Le dit cookie a été créé lorsque tu as visité la page de préférences de Google, et choisi comme pays la France.

Sinon, je t'assure que tu n'es pas redirigé. Pour preuve: mon IP est française, je n'ai touché à aucune des préférences et je ne suis pas redirigé.

D'ailleurs, pour "contourner cet obstacle", donc pour accèder à google.com (et ses résultats internationaux/américains) malgré ce cookie, il suffit de demander l'URL google.com/ncr (NCR pour "no cookie redirect" vraisemblablement). Le lien est même présent sur google.fr avec l'ancre "google.com in english".

Preuve encore qu'"il ne semble pas interdit" d'accéder à google.com depuis une IP française

/* Et donc sinon, oui on peut bloquer qui on veut. C'est ton site, tu y admets qui tu veux. */

Nope. Google fait la sélection à l'aide des entêtes HTTP envoyés par le navigateur, qui indiquent que la langue préférée est le français. Par exemple mon firefox envoie :

Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3

Ensuite c'est éventuellement sauvegardé dans un cookie, mais lors de la première visite c'est bien ce qui se passe.

<li id="pave">>> You Wot ?: the history of the English language</li>

This code is not valid HTML 4.01 transitional.

Commence par remplacer les > dans le texte par ">", ça pourra t'éviter de mauvaises surprises par la suite.

Ensuite, ce que tu récupères par getElementById() n'est pas une chaîne de caractères, mais un objet de type HTMLElement (dans le cas d'un LI, c'est même un objet HTMLLIElement). On ne peut donc pas compter le nombre de caractères qu'il contient, puisqu'il n'en contient pas. Il t'appartient de récupérer son contenu sous forme de chaîne de caractères, mais pas avec value comme le suggère webor, car si j'en crois la documentation du DOM pour l'élément LI, l'attribut value n'a rien à voir avec le contenu textuel de cet élément (c'est une histoire de numérotation des éléments de liste).

Le plus simple serait d'utiliser "innerText", mais ça ne marche qu'avec Internet Explorer.

Donc il te faut récupérer la valeur du noeud texte, premier enfant de ton élément LI :

function compte()
{
					var pave=document.getElementById("pave");
					document.write(pave.firstChild.nodeValue.length);
}

Ça devrait mieux marcher comme ça.

Attention cependant, si tu as d'autres éléments HTML dans le contenu de ton LI, s'il est balisé quoi, ça ne marchera pas. Mais la solution dans ce cas est un poil plus compliquée.

C'est tout de même incroyable cette ségrégation basée sur un "geek profond" sans le moindre support réel.

Arrêtez un peu ! Soyez réalistes, retirez vos préjugés de geeks!

Nous sommes réalistes. Il n'existe pas de bonnes raison pour quelqu'un qui n'y connaît rien de prendre une solution Windows plutôt que Linux. C'est transparent tant qu'on n'utilise que le transfert FTP. Par ailleurs, PHP est plus souvent préinstallé sur des hébergements mutualisés Linux que Windows. Ensuite, il y a la gestion du serveur Web proprement dit. Sans avoir la main sur le serveur complet, (ce qui ne semble pas être la demande de Krys, si je ne m'abuse), Apache est beaucoup plus configurable (.htaccess) au niveau répertoire que IIS.

Payant / gratuit. Ok, Windows a été longtemps le payant, le "méchant" car payant et Linux le gentil gratuit... Mais rien ne peu naître si il n'y a pas un peu de concurrence. Les 2 devraient se remercier.

Moi même ayant été un fan (pour pas dire geek) de XWindow, je pourrais me dire que Linux n'est qu'une pâle copie pitoyable d'Unix. Mais je n'en ferais rien car c'est un bon système. Au même titre que les autres, adaptés aux besoins de telle ou telle utilisation. Mais, par pitié, grandissez et arrêtez cette "geek mania" qui pourrie l'informatique.

C'est bien de cela qu'il s'agit. Si tu lis correctement nos réponses, tu verras que pour l'utilisation qui est demandée, à savoir un hébergemetn bête et méchant pour quelqu'un qui ne sait pas comment ça marche, on prend l'offre standard qui est l'hébergement LAMP. Ça ne te viendrait pas à l'idée de proposer Linux à un débutant en informatique ? Ça ne nous vient pas à l'idée de proposer Windows à un débutant en matière d'hébergement Web.

Y'a pas plus simple à administrer qu'une serveur Windows.

Mais, il y a Plesk qui permet d'administrer aussi bien un Windows qu'un Linux encore plus simplement.

Il n'est pas ici question d'administrer un serveur, mais d'héberger un site.

Ok merci de ta réponse Findel.

Que chez moi je tourne sous windows, ça n' a rien à voir ? je peux garder mon windows chez moi et choisir l' offre 1 one 1 pour Linux ? ( car moins cher ).

Non ça n'a rien à voir. La plupart des gens qui utilisent un hébergement Linux travaillent sous Windows.

C'est justement la magie d'internet que de faire communiquer des machines différentes.

Salut,

Il faut absolument qu'il y ai l'id de l'article pour identifier cet article.

Rien n'empêche cet id d'être une chaîne de caractères...

personnelllement, linux je n' y connais absolument rien.

L' ASP je ne sais même pas ce que c' est, je suis un débutant ! D' après vous, je fais qquoi ? Windows ou linux ?

PS : je précise qu' il faut que ce soit assez simple.

Dans ce cas, il y a très peu de chances que tu voies une différence, quel que soit ton choix.

Je dirais donc Linux, vu que c'est la configuration la plus courante et pour laquelle tu trouveras plus facilement de l'aide.

Je m'insurge devant cette polémique "Windows est moins bien que Linux" qui date d'un autre temps et qui n'a vraiment pas lieu d'être.

Il est possible de faire tourner Php / MySQL sous Windows en plus d'ASP. Ca ne pse pas de problème et ça marche très bien.

<troll>

Vivivivi. N'empêche que IIS est une catastrophe quand même...

</troll>

C'est moi ou il y a beaucoup plus de femmes que d'hommes qui ont répondu ?

C'est marrant, ça.

Il y a aussi toutes les saloperies de protections du genre norton internet security et compagnie qui ont tendance à bloquer toutes sortes de choses (cookies, referrer, appel à un domaine différent du site en cours, voire même requêtes POST, etc.). Je me suis laissé dire qu'Analytics ne prenait pas en compte les données incomplètes (pas de referrer par exemple).

Et Analytics, contrairement à Xiti, n'a pas d'alternative à JavaScript. Sans compter qu'il doit également ajaxifier pas mal et que ça n'est pas supporté par tous les browsers, même avec javascript.

Poste est présenté comme un get mais en mieux.

Ben non. S'ils existent tous les deux, c'est bêtement parce qu'il ne servent pas à la même chose.

POST sert à envoyer des informations.

GET sert à demander une ressource.

Dans le cadre d'un formulaire de recherche, par exemple, GET est indiqué : tu vas demander le document résultant de la requête. Comme la requête passse dans l'url, il est possible de la bookmarker.

A contrario, dans le cadre d'un formulaire de contact, POST est plus adapté. On ne demande rien, on envoie des infos et en retour on reçoit une confirmation qui n'a pas vocation (ni d'intérêt) à être bookmarké. De plus, la plupart des navigateurs intègrent une sécurité qui fait qu'on ne peut pas renvoyer deux fois les mêmes informations par POST sans confirmation.

Bonjour,

Pour approfondir un peu ce qu'est le design et aller au delà de faire un "beau" site, je te conseille de lire (si tu comprends l'anglais) quelques articles sur Design View.

Tu ne trouvera pas comment faire tel ou tel effet, mais pourquoi le faire, dans quel contexte, etc. Chaque élément d'un design bien fait a une fonction particulière, et n'est pas seulement là pour faire joli. Les sites que tu lies en exemple reflètent assez bien ce que j'essaie de dire.