jcaron

Et donc, que donnent "date" et "date -u"? Jacques.

Il y a deux problématiques possibles: - le serveur (ou en tous cas les processus qui te concernent) n'utilisent pas le bon fuseau horaire - l'heure UTC est fausse. Si tu as un accès ssh, tape "date" et regarde le nom du fuseau horaire. Ca devrait être CEST. Si tu as quelque chose du genre EST, c'est un problème de fuseau horaire. Si tu as bien CEST, il faut changer l'heure UTC du serveur. Suivant le cas on t'indiquera la procédure à suivre. Tu peux aussi taper "date -u", qui te donnera l'heure UTC: tu devrais avoir 2 heures de décalage par rapport à l'heure en France en ce moment. Ca aiderait aussi si tu nous disais si tu as un accès ssh, un panneau de contrôle (lequel), etc. Jacques.

Il y a bien une redirection, mais elle se fait en plusieurs temps curl -vL 'http://www.hycity-car.com/index.php?maf=11&idloc=87' [...] < HTTP/1.1 301 Moved Permanently < Location: http://www.hycity-car.com/index.php?maf=article&idloc=87 [...] < HTTP/1.1 301 Moved Permanently < Location: http://www.hycity-car.com/index.php?t=nouv...le&idloc=87 Ceci dit, ça ne devrait pas empêcher les choses. Mais, question idiote, tu envoies bien directement sur les bons liens au moins? Sinon la page en question a-t-elle été visitée par Google depuis le changement? Tu as un sitemap? Jacques.

La plupart des requêtes DNS se font sur le port UDP 53. Il n'y a que les transferts de zone et certains resolves qui utilisent TCP. Et même pour TCP, les lignes que tu donnes disent qu'il écoute sur 10.0.0.1 et 127.0.0.1 seulement, donc à moins que tu n'aies du NAT quelque part qui renvoie ton adresse IP publique vers l'une de ces deux adresses, il ne répondra pas aux requêtes externes. Pour tester, c'est toujours une bonne idée que de le faire depuis une autre machine, et en précisant avec @ le serveur que tu interroges avec dig. Jacques.

Même réponse que Jean-Luc, donne nous des exemples (réels) pour tester. Maintenant, j'avoue que je ne comprends pas trop en quoi c'est un handicap par rapport à Google... Les nouvelles URLs ne sont pas terriblement plus "belles" que les anciennes, tu as toujours une tripotée de paramètres après le "?"... Jacques.

Tu n'as pas répondu à la question: comment se fait le "renvoi" de xxx vers yyy? DNS? Redirection? Frame? Lien? DNS: le HTTP_HOST sur yyy sera xxx Redirection: aucune info dispo Frame ou lien: HTTP_REFERER sur yyy sera xxx Donc si ni HTTP_REFERER ni HTTP_HOST ne contiennent l'info, c'est une redirection HTTP, et en général ça veut dire qu'il n'y a aucun moyen de savoir d'où ça vient à ma connaissance. Jacques.

Ton serveur DNS (primaire) ne répond pas. Au choix: - named n'est pas lancé - le port 53 est filtré Là ça impacte la résolution pour l'ensemble de la zone y compris le A (pour 50% de ceux qui ne l'ont pas en cache). Sinon j'avais loupé le problème initial sur le MX, c'est un classique: quand tu ne mets pas de nom au début de la ligne, ça veut dire "même nom que la ligne précédente" (ça permet de simplifier l'écriture pour le cas où on a plusieurs A pour une même adresse, par exemple). Donc là ton MX s'applique à mail.xbox360france.com. Pour qu'il s'applique à xbox360france.com, déplace la ligne au dessus (avec les NS et le A), ou mets un @ en début de ligne (ou "xbox360franc.com.") . Jacques.

Qui pointe comment? Directement au niveau DNS, ou via une redirection ou un frame? Dans le premier cas, il faut utiliser HTTP_HOST (la méthode la plus simple étant alors un VirtualHost). Dans le deuxième, je ne suis pas sûr qu'il existe de méthode efficace. Dans le troisième tu devrais effectivement avoir quelque chose dans HTTP_REFERER. Jacques.

Tu as bien pensé à mettre à jour ton serial à chaque modif avant de dire à bind de recharger la zone? Les NS indiqués là sont bien ceux qui sont déclarés au niveau du TLD? Comme dit Dan, ce serait plus facile pour débugger si on connaissait le domaine. Sinon c'est pas compliqué, tu te mets à la place d'un resolver DNS, et tu descends l'arbo jusqu'à ton MX: dig NS domaine.com. @a.gtld-servers.net. -> te renvoie les NS Pour chaque NS: dig MX domaine.com. @nom-du-ns Tu peux aussi regarder ce que ça donne avec http://www.squish.net/dnscheck/ c'est assez efficace pour détecter pas mal de problèmes. Jacques.

Je plussoie: JS et/ou insérer quelque chose dans le html qui ne sera téléchargé que si la page est interprétée comme du HTML: image, iframe, voire feuille de style ou JS. Faire bien attention à éviter les mises en cache. Jacques.

Dans le cas d'OVH sur un .com dans hébergement sans option ni rien, suivant le cours du dollar ça leur arrive de vendre à perte la première année... Jacques.

Ben le problème que tu vas avoir c'est que contrairement aux contacts qui sont généralement modifiables très facilement, changer le propriétaire du domaine est souvent nettement plus contraignant, même si ça dépend pas mal du TLD et/ou du registrar. Dans certains cas ils vont te demander de justifier que tu es bien la personne/société indiqué à coups de pièce d'identité, de Kbis, etc. Evidemment si la société n'existe pas ça risque d'être plus difficile. Dans d'autres cas ça va être aussi simple qu'un changement de contact (i.e. confirmation par mail, et puis voilà). Pour le registrar on a compris que c'était donc OVH, pour le TLD c'est quoi? .com, .fr, autre chose? Jacques.

Je confirme que la spec HTML autorise plusieurs "link-types" dans le rel, séparés par des espaces: http://www.w3.org/TR/html4/struct/links.html#adef-rel On va espérer que les moteurs supportent correctement la spec. Par contre je ne comprends pas très bien ton histoire de JS? Jacques.

Les deux, en général, mais ça dépend probablement des registrars et/ou registries (flemme de vérifier le détail): pour les .com et compagnie, les nic-handles sont souvent utilisés que pour les contacts (technique, administratif, de facturation...), alors que le propriétaire est lié directement au domaine. Mais si tu nous expliquais exactement ton problème ce serait probablement plus simple de te répondre précisément. Jacques.

Regarde la taille (width+height) de tes 2 derniers :hover... Jacques.

Ben le "domaine canonique" c'est celui que tu considères comme étant le "bon", les autres étant des variations que tu renvoies vers lui. Genre tu décides que "officiellement", ton domaine c'est "mon-domaine.com", alors tu renvoies "mondomaine.com", "mon-domaine.fr" et "mondomaine.fr" vers "mon-domaine.com". Jacques.

Ne pas oublier monsite.com (i.e. avoir toutes les combinaisons avec et sans tiret, .fr et .com). Et gérer des redirections vers un domaine "canonique". Le risque de confusion dépend énormément du mode de communication: via des liens (moteurs de recherche, mails, bookmarks...) évidemment ce n'est pas trop un problème. Si tu fais de la pub sur des supports non interactifs (i.e. sur lesquels on ne clique pas): TV, radio, affichage, magazines, prospectus... alors le risque est plus important, de même que par le bouche à oreille dans le sens original du terme (i.e. par voie orale plutôt que par mail). Note qu'au delà des problématiques de tirets et d'extension, il y a les fautes d'orthographes plus ou moins évidentes. Plus c'est simple et non ambigu, mieux c'est. Jacques.

Je dirais que ton problème original est que tu cherches à remplacer "Course" (avec une majuscule) alors que tu lui dis de remplacer "course" (sans). Non? Jacques.

Sans base de données du tout ça risque d'être bien difficile (ou en cas très peu performant). Si tu ne peux pas utiliser de bdd sur ton site, tu peux faire appel à un moteur de recherche externe (par exemple une custom search Google, limitée à ton site). Sinon la seule méthode c'est de faire un script qui fait l'équivalent d'un grep: trouver tous les fichiers de ton site, et les ouvrir un par un pour voir si le texte cherché est dedans. A moins que ton site soit vraiment très petit c'est à déconseiller très fortement. Et si tu ne peux pas avoir de base de données sur ton site, tu ne peux probablement pas avoir de scripts non plus? Et si ce n'est pas une limite de l'hébergement, pourquoi la restriction? Jacques.

Tu as comparé les configs, en particulier celles d'Apache (httpd.conf), de php (phi.ini) et de mysql? Jacques.

Et le fichier est bien encodé en UTF-8? Parce que si le XML dit que c'est de l'UTF-8 alors qu'ils sont en ISO, ça va forcément poser problème. Après il peut y avoir la problématique des fontes utilisées qui n'ont pas forcément les caractères accentués? Je dis ça un peu au hasard, je ne suis pas un grand spécialiste du Flash... Jacques.

Tu veux te barrer de quelque part, tu obtiens ce que tu veux d'abord, et tu résilies ensuite (si tu joues le jeu, sinon tu arrêtes juste de payer). Il est très loin d'être impossible que ton client veuille aller voir ailleurs. Et même si le client ne veut pas partir, l'argument est loin d'être bidon. Si tu es tout seul, il court assez sérieusement le risque de se retrouver avec un site inutilisable si jamais il t'arrive quelque chose. Il est normal (et légitime) que si le site a la moindre importance pour lui qu'il puisse envisager la continuité du service, ne serait-ce qu'en étant sûr qu'il a accès au nécessaire pour pouvoir faire ce qu'il veut ou au moins récupérer le nécessaire et le transférer ailleurs. Et je pense qu'il doit être possible pour toi de lui fournir ça sans compromettre le reste. Après évidemment il se pose le problème de la propriété intellectuelle liée aux développements éventuels, et là il n'y a que le contrat qui permette de trancher. Si le contrat n'est pas assez précis, c'est plus compliqué évidemment. Mon avis personnel est que quelqu'un lui souffle dans l'oreille, et on sait ce que ça veut dire... Jacques.

Une chose me semble quasi-certaine: il ne demande pas ces codes sans raison. Qu'il veuille déménager ça ailleurs, y accéder lui-même, confier la gestion de tout ça à quelqu'un en interne, je ne sais quoi d'autre, il pense qu'il a besoin de ces codes d'accès. Essaie déjà de comprendre pourquoi il veut y avoir accès, et plus précisément ce qu'il veut faire. Une fois que tu as compris ce qu'il veut faire, tu pourras probablement trouver la bonne solution pour qu'il puisse y arriver... Jacques.

file_get_contents + file_put_contents? http://us2.php.net/manual/en/function.file-get-contents.php http://us2.php.net/manual/en/function.file-put-contents.php Evidemment tu t'assureras avant tout que tu as le droit de le faire... Jacques.

Ca ne répond pas à ta question, mais rue89 n'est pas hébergé chez Gandi. Il faut que tu apprennes à faire la différence entre le registrar (qui gère le domaine) et l'hébergeur (qui gère le serveur web), qui ne sont pas forcément les mêmes. Et en plus il y peut y avoir des redirections en jeu. Et je ne pense pas qu'il existe d'outil exhaustif qui puisse te dire quels domaines sont hébergés sur une IP donnée (même s'il y a des services qui peuvent en lister certains) et encore moins quels domaines sont hébergés par un hébergeur donné (qui peut avoir un très grand nombre de serveurs et donc d'adresses IP). Ceci dit, se connecter sur quelques serveurs à un instant X ne t'apportera de toutes façons pas forcément beaucoup d'informations sur la qualité du service fourni. L'idéal est normalement de consulter les engagements pris par les uns et les autres, et surtout les compensations s'ils ne respectent pas leurs engagements (parce qu'un SLA à 100% c'est impossible, mais certains le proposeront quand même, mais sans aucune compensation s'ils ne le respectent pas, par exemple). Jacques.