Je cherche à acheter un nom de domaine et à héberger mon site. Quant à
l'hébergeur, mon choix se porterait volontiers sur Sivit (prix très
corrects, et d'après ce que j'ai pu voir ici, les clients en sont plutôt
satisfaits).
Bien. Maintenant le nom de domaine. Je préfèrerais avoir un nom en .fr,
quoique ce soit uniquement pour mes raisons d'euphonie... Donc, je vous
demande :
- quel intérêt technique y a-t-il à choisir un .fr plutôt qu'un .com ?
- quel registrar choisir pour un .fr ? J'ai vu qu'OVH les proposait pour
20 euros par an, alors qu'ailleurs, c'est souvent dans les 40 euros.
OVH, bon ou pas bon ?
- j'ai entendu parler de cas où des registrars se permettaient de
modifier à la volée les pages visitées. Avez-vous des noms à éviter ?
- vaut-il mieux que les comptes mail soient gérés par le registrar ou
par l'hébergeur ? Quelle différence cela fait-il ?
Etant complètement novice dans ce domaine, je voudrais savoir quels sont
les pièges à éviter : qu'est-ce que la redirection ? j'ai lu dans un
post précédent que la redirection transparente était synonyme de mauvais
référencement, de pages transférées via des frames, bref, ça m'a l'air
mauvais, donc à éviter. Quels sont les autres choix ?
Pour être concret, sommes-nous bien d'accord que si j'achète un nom de
domaine machin.fr chez X, et si j'héberge mon site chez Y, alors
lorsqu'un visiteur tapera machin.fr dans son navigateur, il accèdera à
mon site chez Y (et que machin.fr reste bien l'URL affichée dans le
navigateur) ? Idem pour un bookmark, c'est bien machin.fr qui est
bookmarké ?
- rigidité de la charte et du choix possible du nom (mais contraintes amenées à disparaitre courant 2004)
En partie seulement, à moins qu'ils aient poussé leur débat, ça restera pour les sociétés, associations, marques, ...
Non, ca sera généralisé.
Cf http://www.afnic.fr/actu/nouvelles/nommage/CP20040120 (conférence de demain), je cite: En 2004, la suppression du "droit au nom"(1) est une nouvelle étape.
Cette évolution se réalisera en deux temps
* au second trimestre 2004, toutes les personnes identifiables en ligne sur des bases de données publiques et nationales (entreprises, artisans, associations immatriculées à l'INSEE, détenteurs de marques...), pourront obtenir le nom de domaine qu'elles souhaitent sans que ce dernier figure sur quelque document que ce soit ;
* quelques mois plus tard, cette possibilité sera étendue à toutes les personnes physiques ou morales -ayant un lien avec la France- non identifiables à partir de bases de données publiques en ligne (particuliers, associations non immatriculées à l'INSEE...).
Patrick.
- rigidité de la charte et du choix possible du nom (mais contraintes
amenées à disparaitre courant 2004)
En partie seulement, à moins qu'ils aient poussé leur débat, ça restera
pour les sociétés, associations, marques, ...
Non, ca sera généralisé.
Cf http://www.afnic.fr/actu/nouvelles/nommage/CP20040120 (conférence de
demain), je cite:
En 2004, la suppression du "droit au nom"(1) est une nouvelle étape.
Cette évolution se réalisera en deux temps
* au second trimestre 2004, toutes les personnes identifiables en
ligne sur des bases de données publiques et nationales (entreprises,
artisans, associations immatriculées à l'INSEE, détenteurs de
marques...), pourront obtenir le nom de domaine qu'elles souhaitent
sans que ce dernier figure sur quelque document que ce soit ;
* quelques mois plus tard, cette possibilité sera étendue à toutes les
personnes physiques ou morales -ayant un lien avec la France- non
identifiables à partir de bases de données publiques en ligne
(particuliers, associations non immatriculées à l'INSEE...).
- rigidité de la charte et du choix possible du nom (mais contraintes amenées à disparaitre courant 2004)
En partie seulement, à moins qu'ils aient poussé leur débat, ça restera pour les sociétés, associations, marques, ...
Non, ca sera généralisé.
Cf http://www.afnic.fr/actu/nouvelles/nommage/CP20040120 (conférence de demain), je cite: En 2004, la suppression du "droit au nom"(1) est une nouvelle étape.
Cette évolution se réalisera en deux temps
* au second trimestre 2004, toutes les personnes identifiables en ligne sur des bases de données publiques et nationales (entreprises, artisans, associations immatriculées à l'INSEE, détenteurs de marques...), pourront obtenir le nom de domaine qu'elles souhaitent sans que ce dernier figure sur quelque document que ce soit ;
* quelques mois plus tard, cette possibilité sera étendue à toutes les personnes physiques ou morales -ayant un lien avec la France- non identifiables à partir de bases de données publiques en ligne (particuliers, associations non immatriculées à l'INSEE...).
Patrick.
Stephane Kanschine
Dans , Patrick tapotait :
Non, ca sera généralisé.
Cf http://www.afnic.fr/actu/nouvelles/nommage/CP20040120 (conférence de demain), je cite: En 2004, la suppression du "droit au nom"(1) est une nouvelle étape.
Aie, la madame de l'Afnic n'avait précisé que le premier point. Merci pour le lien.
-- Stephane Kanschine Amadouer l'anti-spam pour me répondre
Dans <pan.2004.01.19.13.09.56.726240.18832@deepcore.org>, Patrick
tapotait :
Non, ca sera généralisé.
Cf http://www.afnic.fr/actu/nouvelles/nommage/CP20040120 (conférence
de demain), je cite:
En 2004, la suppression du "droit au nom"(1) est une nouvelle étape.
Aie, la madame de l'Afnic n'avait précisé que le premier point. Merci
pour le lien.
--
Stephane Kanschine
Amadouer l'anti-spam pour me répondre
Cf http://www.afnic.fr/actu/nouvelles/nommage/CP20040120 (conférence de demain), je cite: En 2004, la suppression du "droit au nom"(1) est une nouvelle étape.
Aie, la madame de l'Afnic n'avait précisé que le premier point. Merci pour le lien.
-- Stephane Kanschine Amadouer l'anti-spam pour me répondre
Vincent
Merci pour vos réponse claires et circonstanciées.
Patrick wrote:
- j'ai entendu parler de cas où des registrars se permettaient de modifier à la volée les pages visitées. Avez-vous des noms à éviter ?
Vous pouvez préciser ? En effet un registrar n'est pas forcément un hébergeur : physiquement les pages de votre site web peuvent très bien être sur une machine qui n'est pas gérée par le registrar. La seule chose à laquelle votre question me fait penser c'est 1) les registrars qui font des redirections avec un popup de publicité (mais il y en a peu, je n'ai pas d'exemples en tête)
Je crois que c'est de cela qu'il s'agissait : quelqu'un qui se plaignait sur le forum d'un hébergeur qu'il y a avait de la pub sur son site. L'hébergeur rejetait, à juste titre si j'ai bonne mémoire, la faute sur le registrar.
Mais sinon, si vous regroupez, je pense qu'il est plus simple de mettre le mail du côté de l'hébergeur.
Parfait. Ca me convient parfaitement.
Redirection non transparente (auquel cas l'internaute voit la vraie adresse du site dans sa barre de navigation), ou (et pour quelque chose de professionnel, c'est ca qu'il faut regarder, et oublier les histoires de redirection), hébergement réel, en utilisant donc a priori les DNS de votre hébergeur web au niveau du domaines.
Hébergement réel s'oppose donc à redirection (transparente ou pas) ? Très bien. Par curiosité, quand la redirection s'impose-t-elle ? Avez-vous un site à me recommander pour que je puisse un peu tirer au clair ces histoires ?
Pour être concret, sommes-nous bien d'accord que si j'achète un nom de domaine machin.fr chez X, et si j'héberge mon site chez Y, alors lorsqu'un visiteur tapera machin.fr dans son navigateur, il accèdera à mon site chez Y (et que machin.fr reste bien l'URL affichée dans le navigateur) ? Idem pour un bookmark, c'est bien machin.fr qui est bookmarké ?
Oui, si machin.fr est renseigné avec les DNS de l'hébergeur Y et si tout est configuré correctement partout (l'hébergeur Y doit notamment déclarer machin.Fr comme ``site virtuel'' dans la configuration de ses serveurs web).
Clair. Merci encore.
Merci pour vos réponse claires et circonstanciées.
Patrick wrote:
- j'ai entendu parler de cas où des registrars se permettaient de
modifier à la volée les pages visitées. Avez-vous des noms à éviter ?
Vous pouvez préciser ?
En effet un registrar n'est pas forcément un hébergeur : physiquement les
pages de votre site web peuvent très bien être sur une machine qui n'est
pas gérée par le registrar.
La seule chose à laquelle votre question me fait penser c'est
1) les registrars qui font des redirections avec un popup de publicité
(mais il y en a peu, je n'ai pas d'exemples en tête)
Je crois que c'est de cela qu'il s'agissait : quelqu'un qui se plaignait
sur le forum d'un hébergeur qu'il y a avait de la pub sur son site.
L'hébergeur rejetait, à juste titre si j'ai bonne mémoire, la faute sur
le registrar.
Mais sinon, si vous regroupez, je pense qu'il est plus simple de mettre
le mail du côté de l'hébergeur.
Parfait. Ca me convient parfaitement.
Redirection non transparente (auquel cas l'internaute voit la vraie
adresse du site dans sa barre de navigation), ou (et pour quelque chose
de professionnel, c'est ca qu'il faut regarder, et oublier les histoires
de redirection), hébergement réel, en utilisant donc a priori les DNS de
votre hébergeur web au niveau du domaines.
Hébergement réel s'oppose donc à redirection (transparente ou pas) ?
Très bien. Par curiosité, quand la redirection s'impose-t-elle ?
Avez-vous un site à me recommander pour que je puisse un peu tirer au
clair ces histoires ?
Pour être concret, sommes-nous bien d'accord que si j'achète un nom de
domaine machin.fr chez X, et si j'héberge mon site chez Y, alors
lorsqu'un visiteur tapera machin.fr dans son navigateur, il accèdera à
mon site chez Y (et que machin.fr reste bien l'URL affichée dans le
navigateur) ? Idem pour un bookmark, c'est bien machin.fr qui est
bookmarké ?
Oui, si machin.fr est renseigné avec les DNS de l'hébergeur Y et si tout
est configuré correctement partout (l'hébergeur Y doit notamment déclarer
machin.Fr comme ``site virtuel'' dans la configuration de ses serveurs
web).
Merci pour vos réponse claires et circonstanciées.
Patrick wrote:
- j'ai entendu parler de cas où des registrars se permettaient de modifier à la volée les pages visitées. Avez-vous des noms à éviter ?
Vous pouvez préciser ? En effet un registrar n'est pas forcément un hébergeur : physiquement les pages de votre site web peuvent très bien être sur une machine qui n'est pas gérée par le registrar. La seule chose à laquelle votre question me fait penser c'est 1) les registrars qui font des redirections avec un popup de publicité (mais il y en a peu, je n'ai pas d'exemples en tête)
Je crois que c'est de cela qu'il s'agissait : quelqu'un qui se plaignait sur le forum d'un hébergeur qu'il y a avait de la pub sur son site. L'hébergeur rejetait, à juste titre si j'ai bonne mémoire, la faute sur le registrar.
Mais sinon, si vous regroupez, je pense qu'il est plus simple de mettre le mail du côté de l'hébergeur.
Parfait. Ca me convient parfaitement.
Redirection non transparente (auquel cas l'internaute voit la vraie adresse du site dans sa barre de navigation), ou (et pour quelque chose de professionnel, c'est ca qu'il faut regarder, et oublier les histoires de redirection), hébergement réel, en utilisant donc a priori les DNS de votre hébergeur web au niveau du domaines.
Hébergement réel s'oppose donc à redirection (transparente ou pas) ? Très bien. Par curiosité, quand la redirection s'impose-t-elle ? Avez-vous un site à me recommander pour que je puisse un peu tirer au clair ces histoires ?
Pour être concret, sommes-nous bien d'accord que si j'achète un nom de domaine machin.fr chez X, et si j'héberge mon site chez Y, alors lorsqu'un visiteur tapera machin.fr dans son navigateur, il accèdera à mon site chez Y (et que machin.fr reste bien l'URL affichée dans le navigateur) ? Idem pour un bookmark, c'est bien machin.fr qui est bookmarké ?
Oui, si machin.fr est renseigné avec les DNS de l'hébergeur Y et si tout est configuré correctement partout (l'hébergeur Y doit notamment déclarer machin.Fr comme ``site virtuel'' dans la configuration de ses serveurs web).
Clair. Merci encore.
Patrick
Redirection non transparente (auquel cas l'internaute voit la vraie adresse du site dans sa barre de navigation), ou (et pour quelque chose de professionnel, c'est ca qu'il faut regarder, et oublier les histoires de redirection), hébergement réel, en utilisant donc a priori les DNS de votre hébergeur web au niveau du domaines.
Hébergement réel s'oppose donc à redirection (transparente ou pas) ? Très bien. Par curiosité, quand la redirection s'impose-t-elle ?
Quand vous avez déjà un hébergement (ce qui est quasimment immédiat de nos jours à partir du moment où vous avez une connexion internet, les FAI fournissant toujours un ``espace personnel'') et que vous n'avez pas envie (ou pas les moyens) d'investir dans un hébergement professionnel, bah vous achetez un nom de domaine, et vous faite une redirection: http://www.example.com/ vers http://perso.monfournisseuramoi.fr/monlogin/
Ainsi on trouve votre site en mettant juste http://www.example.com/ mais on voit au final dans le navigateur la ``vraie'' URL (celle de destination), ce qui est perçu comme non ''professionnel''.
Avez-vous un site à me recommander pour que je puisse un peu tirer au clair ces histoires ?
Hum... je vois pas quoi conseiller de pertinents. En général c'est surtout des aspects techniques dont on parle (configuration) un peu partout. Le reste c'est de ``l'esthétique'' :-)
Patrick.
Redirection non transparente (auquel cas l'internaute voit la vraie
adresse du site dans sa barre de navigation), ou (et pour quelque chose
de professionnel, c'est ca qu'il faut regarder, et oublier les
histoires de redirection), hébergement réel, en utilisant donc a priori
les DNS de votre hébergeur web au niveau du domaines.
Hébergement réel s'oppose donc à redirection (transparente ou pas) ?
Très bien. Par curiosité, quand la redirection s'impose-t-elle ?
Quand vous avez déjà un hébergement (ce qui est quasimment immédiat de
nos jours à partir du moment où vous avez une connexion internet, les FAI
fournissant toujours un ``espace personnel'') et que vous n'avez pas
envie (ou pas les moyens) d'investir dans un hébergement professionnel,
bah vous achetez un nom de domaine, et vous faite une redirection:
http://www.example.com/ vers http://perso.monfournisseuramoi.fr/monlogin/
Ainsi on trouve votre site en mettant juste http://www.example.com/
mais on voit au final dans le navigateur la ``vraie'' URL (celle de
destination), ce qui est perçu comme non ''professionnel''.
Avez-vous un site à me recommander pour que je puisse un peu tirer au
clair ces histoires ?
Hum... je vois pas quoi conseiller de pertinents. En général c'est
surtout des aspects techniques dont on parle (configuration) un peu
partout. Le reste c'est de ``l'esthétique'' :-)
Redirection non transparente (auquel cas l'internaute voit la vraie adresse du site dans sa barre de navigation), ou (et pour quelque chose de professionnel, c'est ca qu'il faut regarder, et oublier les histoires de redirection), hébergement réel, en utilisant donc a priori les DNS de votre hébergeur web au niveau du domaines.
Hébergement réel s'oppose donc à redirection (transparente ou pas) ? Très bien. Par curiosité, quand la redirection s'impose-t-elle ?
Quand vous avez déjà un hébergement (ce qui est quasimment immédiat de nos jours à partir du moment où vous avez une connexion internet, les FAI fournissant toujours un ``espace personnel'') et que vous n'avez pas envie (ou pas les moyens) d'investir dans un hébergement professionnel, bah vous achetez un nom de domaine, et vous faite une redirection: http://www.example.com/ vers http://perso.monfournisseuramoi.fr/monlogin/
Ainsi on trouve votre site en mettant juste http://www.example.com/ mais on voit au final dans le navigateur la ``vraie'' URL (celle de destination), ce qui est perçu comme non ''professionnel''.
Avez-vous un site à me recommander pour que je puisse un peu tirer au clair ces histoires ?
Hum... je vois pas quoi conseiller de pertinents. En général c'est surtout des aspects techniques dont on parle (configuration) un peu partout. Le reste c'est de ``l'esthétique'' :-)
Patrick.
Vincent
Patrick wrote:
Quand vous avez déjà un hébergement (ce qui est quasimment immédiat de nos jours à partir du moment où vous avez une connexion internet, les FAI fournissant toujours un ``espace personnel'') et que vous n'avez pas envie (ou pas les moyens) d'investir dans un hébergement professionnel, bah vous achetez un nom de domaine, et vous faite une redirection: http://www.example.com/ vers http://perso.monfournisseuramoi.fr/monlogin/
Encore une petite question si vous voulez bien... Prenons votre exemple d'un site hébergé par le fournisseur : http://perso.fournisseur.fr/login Si j'ai bien compris, grosso modo, lorsqu'un visiteur tape dans son navigateur cette adresse, celui-ci interroge des DNS (ceux du fournisseur a priori), qui lui renvoient l'adresse IP du serveur hébergeur.
Si maintenant j'achète le domaine exemple.com, je ne saisis pas très bien pourquoi il faut faire une redirection : ne pourrait-on pas imaginer que les DNS font pointer deux noms différents vers la même adresse IP, c'est-à-dire schématiquement avoir une table du genre : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com A.B.C.D
plutôt que : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com http://perso.fournisseur.fr/login
(c'est ainsi que je me représente le mécanisme de redirection, une espèce d'alias, peut-être est-ce plus complexe en fait...)
Est-ce parce que l'hébergeur (le fournisseur) n'est pas forcément prêt à communiquer l'adresse A.B.C.D au registrar de exemple.com ? Le fournisseur ne pourrait-il pas lui-même mettre à jour les DNS pour arriver au premier cas ? Ou cela demande-t-il trop de travail de maintenance ?
Patrick wrote:
Quand vous avez déjà un hébergement (ce qui est quasimment immédiat de
nos jours à partir du moment où vous avez une connexion internet, les FAI
fournissant toujours un ``espace personnel'') et que vous n'avez pas
envie (ou pas les moyens) d'investir dans un hébergement professionnel,
bah vous achetez un nom de domaine, et vous faite une redirection:
http://www.example.com/ vers http://perso.monfournisseuramoi.fr/monlogin/
Encore une petite question si vous voulez bien...
Prenons votre exemple d'un site hébergé par le fournisseur :
http://perso.fournisseur.fr/login
Si j'ai bien compris, grosso modo, lorsqu'un visiteur tape dans son
navigateur cette adresse, celui-ci interroge des DNS (ceux du
fournisseur a priori), qui lui renvoient l'adresse IP du serveur hébergeur.
Si maintenant j'achète le domaine exemple.com, je ne saisis pas très
bien pourquoi il faut faire une redirection : ne pourrait-on pas
imaginer que les DNS font pointer deux noms différents vers la même
adresse IP, c'est-à-dire schématiquement avoir une table du genre :
http://perso.fournisseur.fr/login A.B.C.D
http://www.exemple.com A.B.C.D
plutôt que :
http://perso.fournisseur.fr/login A.B.C.D
http://www.exemple.com http://perso.fournisseur.fr/login
(c'est ainsi que je me représente le mécanisme de redirection, une
espèce d'alias, peut-être est-ce plus complexe en fait...)
Est-ce parce que l'hébergeur (le fournisseur) n'est pas forcément prêt à
communiquer l'adresse A.B.C.D au registrar de exemple.com ? Le
fournisseur ne pourrait-il pas lui-même mettre à jour les DNS pour
arriver au premier cas ? Ou cela demande-t-il trop de travail de
maintenance ?
Quand vous avez déjà un hébergement (ce qui est quasimment immédiat de nos jours à partir du moment où vous avez une connexion internet, les FAI fournissant toujours un ``espace personnel'') et que vous n'avez pas envie (ou pas les moyens) d'investir dans un hébergement professionnel, bah vous achetez un nom de domaine, et vous faite une redirection: http://www.example.com/ vers http://perso.monfournisseuramoi.fr/monlogin/
Encore une petite question si vous voulez bien... Prenons votre exemple d'un site hébergé par le fournisseur : http://perso.fournisseur.fr/login Si j'ai bien compris, grosso modo, lorsqu'un visiteur tape dans son navigateur cette adresse, celui-ci interroge des DNS (ceux du fournisseur a priori), qui lui renvoient l'adresse IP du serveur hébergeur.
Si maintenant j'achète le domaine exemple.com, je ne saisis pas très bien pourquoi il faut faire une redirection : ne pourrait-on pas imaginer que les DNS font pointer deux noms différents vers la même adresse IP, c'est-à-dire schématiquement avoir une table du genre : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com A.B.C.D
plutôt que : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com http://perso.fournisseur.fr/login
(c'est ainsi que je me représente le mécanisme de redirection, une espèce d'alias, peut-être est-ce plus complexe en fait...)
Est-ce parce que l'hébergeur (le fournisseur) n'est pas forcément prêt à communiquer l'adresse A.B.C.D au registrar de exemple.com ? Le fournisseur ne pourrait-il pas lui-même mettre à jour les DNS pour arriver au premier cas ? Ou cela demande-t-il trop de travail de maintenance ?
François Manchon
"Vincent" a écrit dans le message de news:buipt1$a4$
Si maintenant j'achète le domaine exemple.com, je ne saisis pas très bien pourquoi il faut faire une redirection : ne pourrait-on pas imaginer que les DNS font pointer deux noms différents vers la même adresse IP, c'est-à-dire schématiquement avoir une table du genre : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com A.B.C.D
plutôt que : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com http://perso.fournisseur.fr/login
(c'est ainsi que je me représente le mécanisme de redirection, une espèce d'alias, peut-être est-ce plus complexe en fait...)
C'est effectivement plus complexe.
Le DNS associe un nom de site (et non pas une URL) à une adresse IP: perso.fournisseur.fr => A.B.C.D
Le serveur Web (Apache ou autre) associe une URL à un répertoire: http://perso.fournisseur.fr/login => fichiers de l'utilisateur "login" sur le serveur "perso.fournisseur.fr"
La redirection est un mécanisme prévu par HTTP: Le navigateur consulte l'URL http://www.exemple.com. La réponse contient un code de redirection et l'URL à utiliser.
Ciao,
François
"Vincent" <vincent.@wanadoo.fr> a écrit dans le message de
news:buipt1$a4$1@news-reader4.wanadoo.fr...
Si maintenant j'achète le domaine exemple.com, je ne saisis pas très
bien pourquoi il faut faire une redirection : ne pourrait-on pas
imaginer que les DNS font pointer deux noms différents vers la même
adresse IP, c'est-à-dire schématiquement avoir une table du genre :
http://perso.fournisseur.fr/login A.B.C.D
http://www.exemple.com A.B.C.D
plutôt que :
http://perso.fournisseur.fr/login A.B.C.D
http://www.exemple.com http://perso.fournisseur.fr/login
(c'est ainsi que je me représente le mécanisme de redirection, une
espèce d'alias, peut-être est-ce plus complexe en fait...)
C'est effectivement plus complexe.
Le DNS associe un nom de site (et non pas une URL) à une adresse IP:
perso.fournisseur.fr => A.B.C.D
Le serveur Web (Apache ou autre) associe une URL à un répertoire:
http://perso.fournisseur.fr/login => fichiers de l'utilisateur "login"
sur le serveur "perso.fournisseur.fr"
La redirection est un mécanisme prévu par HTTP: Le navigateur consulte
l'URL http://www.exemple.com. La réponse contient un code de redirection et
l'URL à utiliser.
"Vincent" a écrit dans le message de news:buipt1$a4$
Si maintenant j'achète le domaine exemple.com, je ne saisis pas très bien pourquoi il faut faire une redirection : ne pourrait-on pas imaginer que les DNS font pointer deux noms différents vers la même adresse IP, c'est-à-dire schématiquement avoir une table du genre : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com A.B.C.D
plutôt que : http://perso.fournisseur.fr/login A.B.C.D http://www.exemple.com http://perso.fournisseur.fr/login
(c'est ainsi que je me représente le mécanisme de redirection, une espèce d'alias, peut-être est-ce plus complexe en fait...)
C'est effectivement plus complexe.
Le DNS associe un nom de site (et non pas une URL) à une adresse IP: perso.fournisseur.fr => A.B.C.D
Le serveur Web (Apache ou autre) associe une URL à un répertoire: http://perso.fournisseur.fr/login => fichiers de l'utilisateur "login" sur le serveur "perso.fournisseur.fr"
La redirection est un mécanisme prévu par HTTP: Le navigateur consulte l'URL http://www.exemple.com. La réponse contient un code de redirection et l'URL à utiliser.
Ciao,
François
Patrick
(c'est ainsi que je me représente le mécanisme de redirection, une espèce d'alias, peut-être est-ce plus complexe en fait...)
Comme l'a très bien dit François, il est important de comprendre que les DNS ne s'occupent que de la partie résolution de noms, à savoir la correspondance entre IP et noms. Ca a été inventé bien avant le web, et donc en particulier un serveur DNS ne manipule pas de données applicatives, comme une URL. Il ne sait pas ce que c'est.
En gros, pour résumer, dans le processus d'accès à une page Web le serveur DNS lie un nom à une adresse IP le serveur Web lie une URL à un répertoire sur le disque dur (ou à une autre URL en cas de redirection).
Les deux opérations sont à 2 niveaux différents, et indépendantes.
Est-ce parce que l'hébergeur (le fournisseur) n'est pas forcément prêt à communiquer l'adresse A.B.C.D au registrar de exemple.com ? Le
L'adresse IP est connue, il suffit de faire une résolution du nom. Mais cela ne suffit pas, il faut configurer la partie applicative (serveur DNS).
Vous pourriez très bien mettre dans les DNS www.exemple.com <=> A.B.C.D et la partie résolution DNS fonctionnerait correctement (pas de message d'erreur style ``hôte inconnu'').
La requête (HTTP) arrive alors sur le serveur Web qui écoute sur A.B.C.D Là, si ce serveur n'est pas configuré, il recoit une requête pour http://www.exemple.com/ et lui il ne sait pas ce que c'est comme site Web Si c'était du mail, il rejeterait en disant unknown, dans le Web, en général, le serveur va répondre avec succès, mais avec une page qui n'a probablement rien à voir avec ce qu'on attend sur http://www.exemple.com/
Il faut donc le configurer explicitement: (liste non exhaustive, mais on couvre les cas les plus fréquents) - soit lui faire reconnaître www.exemple.com comme le nom d'un site qu'il gère, et lui associer un répertoire sur le disque - soit lui demander de faire une redirection HTTP, c'est à dire de répondre au client HTTP que l'URL n'est plus la bonne, tout en fournissant la bonne, l'URL de destination.
fournisseur ne pourrait-il pas lui-même mettre à jour les DNS pour arriver au premier cas ? Ou cela demande-t-il trop de travail de maintenance ?
Ce n'est pas tant une quantité de travail. C'est juste qu'il faut deux configurations, à deux niveaux différents: au niveau DNS, et au niveau HTTP.
Patrick.
(c'est ainsi que je me représente le mécanisme de redirection, une
espèce d'alias, peut-être est-ce plus complexe en fait...)
Comme l'a très bien dit François, il est important de comprendre que les
DNS ne s'occupent que de la partie résolution de noms, à savoir la
correspondance entre IP et noms.
Ca a été inventé bien avant le web, et donc en particulier un serveur DNS
ne manipule pas de données applicatives, comme une URL. Il ne sait pas ce
que c'est.
En gros, pour résumer, dans le processus d'accès à une page Web
le serveur DNS lie un nom à une adresse IP
le serveur Web lie une URL à un répertoire sur le disque dur (ou à une
autre URL en cas de redirection).
Les deux opérations sont à 2 niveaux différents, et indépendantes.
Est-ce parce que l'hébergeur (le fournisseur) n'est pas forcément prêt à
communiquer l'adresse A.B.C.D au registrar de exemple.com ? Le
L'adresse IP est connue, il suffit de faire une résolution du nom.
Mais cela ne suffit pas, il faut configurer la partie applicative
(serveur DNS).
Vous pourriez très bien mettre dans les DNS
www.exemple.com <=> A.B.C.D
et la partie résolution DNS fonctionnerait correctement (pas de message
d'erreur style ``hôte inconnu'').
La requête (HTTP) arrive alors sur le serveur Web qui écoute sur A.B.C.D
Là, si ce serveur n'est pas configuré, il recoit une requête pour
http://www.exemple.com/ et lui il ne sait pas ce que c'est comme site Web
Si c'était du mail, il rejeterait en disant unknown, dans le Web, en
général, le serveur va répondre avec succès, mais avec une page qui n'a
probablement rien à voir avec ce qu'on attend sur http://www.exemple.com/
Il faut donc le configurer explicitement:
(liste non exhaustive, mais on couvre les cas les plus fréquents)
- soit lui faire reconnaître www.exemple.com comme le nom d'un site qu'il
gère, et lui associer un répertoire sur le disque
- soit lui demander de faire une redirection HTTP, c'est à dire de
répondre au client HTTP que l'URL n'est plus la bonne, tout en
fournissant la bonne, l'URL de destination.
fournisseur ne pourrait-il pas lui-même mettre à jour les DNS pour
arriver au premier cas ?
Ou cela demande-t-il trop de travail de maintenance ?
Ce n'est pas tant une quantité de travail. C'est juste qu'il faut deux
configurations, à deux niveaux différents: au niveau DNS, et au niveau
HTTP.
(c'est ainsi que je me représente le mécanisme de redirection, une espèce d'alias, peut-être est-ce plus complexe en fait...)
Comme l'a très bien dit François, il est important de comprendre que les DNS ne s'occupent que de la partie résolution de noms, à savoir la correspondance entre IP et noms. Ca a été inventé bien avant le web, et donc en particulier un serveur DNS ne manipule pas de données applicatives, comme une URL. Il ne sait pas ce que c'est.
En gros, pour résumer, dans le processus d'accès à une page Web le serveur DNS lie un nom à une adresse IP le serveur Web lie une URL à un répertoire sur le disque dur (ou à une autre URL en cas de redirection).
Les deux opérations sont à 2 niveaux différents, et indépendantes.
Est-ce parce que l'hébergeur (le fournisseur) n'est pas forcément prêt à communiquer l'adresse A.B.C.D au registrar de exemple.com ? Le
L'adresse IP est connue, il suffit de faire une résolution du nom. Mais cela ne suffit pas, il faut configurer la partie applicative (serveur DNS).
Vous pourriez très bien mettre dans les DNS www.exemple.com <=> A.B.C.D et la partie résolution DNS fonctionnerait correctement (pas de message d'erreur style ``hôte inconnu'').
La requête (HTTP) arrive alors sur le serveur Web qui écoute sur A.B.C.D Là, si ce serveur n'est pas configuré, il recoit une requête pour http://www.exemple.com/ et lui il ne sait pas ce que c'est comme site Web Si c'était du mail, il rejeterait en disant unknown, dans le Web, en général, le serveur va répondre avec succès, mais avec une page qui n'a probablement rien à voir avec ce qu'on attend sur http://www.exemple.com/
Il faut donc le configurer explicitement: (liste non exhaustive, mais on couvre les cas les plus fréquents) - soit lui faire reconnaître www.exemple.com comme le nom d'un site qu'il gère, et lui associer un répertoire sur le disque - soit lui demander de faire une redirection HTTP, c'est à dire de répondre au client HTTP que l'URL n'est plus la bonne, tout en fournissant la bonne, l'URL de destination.
fournisseur ne pourrait-il pas lui-même mettre à jour les DNS pour arriver au premier cas ? Ou cela demande-t-il trop de travail de maintenance ?
Ce n'est pas tant une quantité de travail. C'est juste qu'il faut deux configurations, à deux niveaux différents: au niveau DNS, et au niveau HTTP.
Patrick.
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, Patrick <patrick+ ecrivait (wrote) :
Bonsoir,
Parmi les inconvénients (non techniques): - prix (forcément plus cher qu'un .COM, les prix registrars étant plus chers)
Pas forcément, il faut voir les services associés.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, Patrick
<patrick+news@deepcore.org> ecrivait (wrote) :
Bonsoir,
Parmi les inconvénients (non techniques):
- prix (forcément plus cher qu'un .COM, les prix registrars étant plus
chers)
Pas forcément, il faut voir les services associés.
Parmi les inconvénients (non techniques): - prix (forcément plus cher qu'un .COM, les prix registrars étant plus chers)
Pas forcément, il faut voir les services associés.
On parle du domaine.
D'autre part j'aurais du dire registry, et pas registrar. Et y a rien à discuter à ce sujet: .COM $6 .FR 14EUR HT
On peut vendre un .COM à 7 ou 8 ou 9 ou 10 euros On ne peut pas vendre un .FR à moins de 14 euros.
Patrick.
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, Patrick <patrick+ ecrivait (wrote) :
On parle du domaine.
Voui.
On peut vendre un .COM à 7 ou 8 ou 9 ou 10 euros On ne peut pas vendre un .FR à moins de 14 euros.
Certes.
On peut vendre un .com ou un .fr à, imaginons, 25 ou 30 euros HT (ce qui est cher, je te le concède), mais y associer la gestion DNS et la fourniture de 10 vrais comptes POP d'une capacité unitaire de 50 Mo, par exemple.
Au bout du compte, l'association réservation du domaine / services proposés peut dans certains cas s'avérer intéressante finacièrement pour le client, mais tout dépend de ses besoins/attentes bien sur.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, Patrick
<patrick+news@deepcore.org> ecrivait (wrote) :
On parle du domaine.
Voui.
On peut vendre un .COM à 7 ou 8 ou 9 ou 10 euros
On ne peut pas vendre un .FR à moins de 14 euros.
Certes.
On peut vendre un .com ou un .fr à, imaginons, 25 ou 30 euros HT (ce qui
est cher, je te le concède), mais y associer la gestion DNS et la
fourniture de 10 vrais comptes POP d'une capacité unitaire de 50 Mo, par
exemple.
Au bout du compte, l'association réservation du domaine / services
proposés peut dans certains cas s'avérer intéressante finacièrement pour
le client, mais tout dépend de ses besoins/attentes bien sur.
dans (in) fr.reseaux.internet.hebergement, Patrick <patrick+ ecrivait (wrote) :
On parle du domaine.
Voui.
On peut vendre un .COM à 7 ou 8 ou 9 ou 10 euros On ne peut pas vendre un .FR à moins de 14 euros.
Certes.
On peut vendre un .com ou un .fr à, imaginons, 25 ou 30 euros HT (ce qui est cher, je te le concède), mais y associer la gestion DNS et la fourniture de 10 vrais comptes POP d'une capacité unitaire de 50 Mo, par exemple.
Au bout du compte, l'association réservation du domaine / services proposés peut dans certains cas s'avérer intéressante finacièrement pour le client, mais tout dépend de ses besoins/attentes bien sur.
