All rights reserved.
Cette liste des questions les plus fréquemment posées est tenue à jour par WDG et a été mise à jour pour la dernière fois le 15 Juillet 2000. (La présente traduction date de Janvier 2001). Elle peut être trouvée aux adresses suivantes :
La traduction en hollandais de ce document est disponible également :
La présente traduction française se trouve sur :
Si vous souhaitez contribuez à cette FAQ, merci d'envoyer un message à <darin@htmlhelp.com>. Toutes les personnes qui ont participé à cette FAQ sont listés à la fin.
N'hésitez pas à contacter le traducteur pour signaler une imprécision, une erreur de traduction, une faute de français que vous pourrez trouver dans ce document : <cedrik.rousseau@insa-rouen.fr>
De nombreux FAIs (Fournisseurs d'accès Internet) offrent de l'espace Web à leur client en connection distante. En régle générale, ce ne sera guère plus de 25 Mo et il pourra y'avoir d'autres restrictions; par exemple l'interdiction d'en faire un usage commercial.
Il y a plusieurs organismes qui offrent de l'espace Web gratuit. L'espace fournit peut s'étendre de 10 à 50 Mo en général. Et à nouveau il y a souvent des limitations, comme l'obligation de rajouter des bandeaux publicitaires. Pour des liens vers des hébergeurs gratuits rendez vous sur <URL:http://www.freewebspace.net/>.
Il y a aussi de nombreux hébergeurs professionnels qui vont vous vendre de l'espace sur leurs serveurs. La gamme de prix est très étendu : de 10 à 1000 FFR par mois ou plus en fonction de vos besoins. Un sous-répertoire d'un serveur (offrant une adresse comme http://www.votreFAI.com/votrenom) vous coutera évidemment moins cher qu'un nom de domaine complet du type http://www.votrenom.com.
Si vous avez une connection permanente à internet, sans doute par une ligne spécialisée, alors le mieux pourrait être d'installer votre propre serveur Web sur une de vos machines. Des serveurs Web sont disponibles pour toutes les architectures existantes.
Si vous souhaitez simplement partager des informations avec des gens sur un réseau local, vous pouvez simplement placer vos fichiers HTML en partage sur le réseau local ou alors installer un serveur Web sur votre ordinateur.
L'ICANN (The Internet Corporation for Assigned Names and Numbers) est l'office chargé d'accréditer les différents organismes capables de déposer directement un nom de domaine. Pour une liste des "registrars" regardez sur <URL:http://www.icann.org/registrars/accredited-list.html>.
Par exemple, Gandi <URL:http://www.gandi.net> propose des tarifs très bas de 12 euros pour l'année.
Jetez un oeil à la charte d'utilisation de votre service d'hébergement. Il est à peu près sûr qu'elle interdit de toucher aux publicités ajoutées. Si vous utilisez une astuce quelconque pour bloquer les pubs, alors votre hébergeur pourra effacer votre compte pour avoir violé la charte.
Cependant, il peut y avoir une alternative. Certains hébergeurs enlèveront les publicités si vous payez pour votre hébergement. D'autres accepteront d'enlever les pubs qui surgissent dans des fenêtres popup si vous ajouter des bannières statiques de publicité sur vos pages vous-même.
Il n'y pas de solution unique mais un bon nombre de facteurs entrent en jeu :
<TITLE> pour
le titre, <H1>, <H2>, etc. pour les
titres de paragraphes et fournissez un champ
alternatif ALT pour vos images.
<META
NAME="keywords" CONTENT="..."> qui apparait dans la zone <HEAD>
de vos pages Web. Cependant les META keywords ont été utillisés
pour piéger les moteurs de recherche, c'est pourquoi la plupart d'entre
eux ignoreront vos mots-clés si vous répétez un mot-clé
donné trop souvent (c'est à dire plus d'une demi-douzaine de
fois).
<META NAME="description" CONTENT="...">
dans le champ <HEAD> d'une page Web, alors certains moteurs
de recherche utiliseront le contenu de cette balise pour décrire votre
site en affichant les résultats d'une recherche. Ceci ne changera pas
le rang de votre site dans les recherches, mais ça aidera les utilisateurs
des moteurs de recherche à comprendre ce que votre site a à
offrir.
L'attribut CONTENT des balises META peut contenir jusqu'à 1022 caractères, mais pas d'autres marqueurs que les entités (&code; etc.).
Peut être voudrez vous prévisualiser votre site avec un navigateur en mode texte comme Lynx pour vous faire une idée de comment votre site apparait à un moteur de recherche. <URL:http://searchenginewatch.com/> est un site Web dédié aux moteurs de recherche et aux stratégies pour auteurs de page Web.
Enfin, notez que certains moteurs de recherche ignoreront les sites hébergés par les services d'hébergement gratuit les plus conus. D'autres moteurs de recherche n'indexent qu'un certain nombre de documents par serveur, ce qui pénalise ces mêmes services gratuits dans la mesure où ils hébergent un grand nombre de documents.
La réponse se trouve sur <URL:http://info.webcrawler.com/mak/projects/robots/exclusion.html>.
La façon la plus fiable est de configurer le serveur pour envoyer une instruction de redirection quand l'ancienne adresse est demandée. Ainsi les navigateurs sauteront directement vers la nouvelle adresse. C'est la façon la plus rapide et la plus efficace et c'est la seule (mentionnée ici) qui permette aux robots indexeurs d'oublier progressivement l'ancienne adresse. Pour les détails de configuration, consultez votre documentation (avec NCSA ou Apache, utiliser une instruction de redirection (Redirect) dans .htaccess).
Si vous ne pouvez créer une redirection Redirect voici deux autres possiblitités qui sont inférieures car elles ne peuvent faire comprendre aux moteurs de recherche que l'ancienne adresse n'existe plus.
<META HTTP-EQUIV="Refresh" CONTENT="x; URL=nouvelle adresse">
ce qui charge la nouvelle adresse après x secondes. Ceci doit se mettre
dans la section HEAD de la page web. Mais si vous faites ceci, ajoutez également
un court texte qui dit quelque chose comme "Cette page a été
déplacée vers la nouvelle adresse" pour les autres navigateurs.
(le problème de la touche retour vient du fait que lorsque vous revenez
en arrière sur la page de redirection, elle vous emmène à
nouveau vers le document que vous venez de tenter de quitter.) La protection par mot de passe est réalisée à travers l'authentification HTTP. Les détails de configuration varient d'un serveur à l'autre, lisez donc la documentation de votre serveur.
Par exemple, si votre serveur est Apache, lisez <URL:http://www.apache.org/docs/misc/FAQ.html#user-authentication>.
La protection par un JavaScript n'est qu'une sécurité de façade. Ils fonctionnent selon l'une de ces deux méthodes : certains scripts convertissent le mot de passe en une adresse, ce qui garde le document secret en limitant le nombre de gens qui connaissent son adresse. Les autres scripts vérifie le mot de passe puis vont à une adresse spécifique, ce qui protège le document uniquement de ceux qui ne vont pas lire le mot de passe écrit dans le code source du JavaScript. Aucun de ces deux méchanismes n'est réellement fiable.
Les navigateurs stockent les documents web dans une mémoire cache; ils mémorisent les documents en local pour accélérer la visualisation répétée des mêmes documents. De plus, de nombreux navigateurs sont configurés pour utiliser un serveur mandataire cache desservant de nombreux utilisateurs (par exemple, les clients d'un FAI, ou les employés d'une grosse société munie d'un firewall... soit une majorité d'internautes). Pour contrôler efficacement comment vos documents sont gardés en cache, vous devez configurer votre serveur pour envoyer les entêtes HTTP appropriés.
L'entête Expires est reconnu par la quasi totalité
des caches. Le document en cache devra être réactualisé
automatiquement une fois expiré. L'entête Expires
doit contenir une date HTTP qui devra être exprimé selon GMT et
non en heure locale.
HTTP 1.1 a intorduit l'entête Cache-Control qui fournit
une plus grande flexibilité pour décrire comment les caches doivent
gérer le document. Pour plus d'information, voir les spécifications
HTTP 1.1 sur <URL:http://www.w3.org/Protocols/>.
Les détails de configuration varient d'un serveur à l'autre, consultez donc votre documentation. Par exemple, si votre serveur est Apache, <URL:http://www.apache.org/docs/mod/mod_expires.html> pourra vous renseigner sur les réglages de l'entête Expires et <URL:http://www.apache.org/docs/mod/mod_headers.html> vous décrira comment régler les autres entêtes.
L'entête Pragma est généralement inefficace
parce que son sens n'est pas standardisé et que peu de cache le traiteront.
Utiliser l'élément <META HTTP-EQUIV=...> dans
un document HTML est également peu efficace car même si certains
navigateurs reconnaissent cette instruction, les autres caches l'ignoreront
complètement.
Une discussion plus poussée peut être trouvée sur <URL:http://www.mnot.net/cache_docs/>.
Vous ne pouvez pas. La source HTML est nécessaire au navigateur pour afficher le document; vous devez envoyer le fichier source complet et non encrypté au navigateur. Même si certains navigateurs n'ont pas la fonction "Voir la source", la plupart l'ont et il est toujours possible de récupérer le document à la main avec telnet par exemple.
Il y a des astuces qui rendent plus difficile la lecture de la source aux utilisateurs non expérimentés. (par exemple, laisser des douzaines de lignes vides au début du code, ou utiliser JavaScript pour empêcher le clic droit). Cependant, tout comme les astuces empêchant les images d'être sauvegardées, ces astuces ont une efficacité très limitée et peuvent causer divers problèmes aux utilisateurs honnêtes.
Vous ne pouvez pas. Les adresses sont fondamentales dans la navigation sur le Web. L'URL est nécessaire au navigateur pour être capable de récupérer le document. Il est donc impossible de masquer une adresse au navigateur.
Vous pouvez cependant empêcher l'adresse d'apparaitre dans la barre d'adresse. Utilisez par exemple des cadres qui découpent en fait la page en un seul cadre. L'adresse visible pour l'utilsateur sera celle du plan de découpage et non celle du document affiché. (Mais l'utilisateur pourra toujours connaitre l'adresse du document, en regardant les propriétés par exemple).
Si vous souhaitiez masquer l'adresse de vos documents pour empêcher les autres de créer des liens pointant sur vos documents, il vous est possible de programmer votre serveur web pour empêcher l'accès à certains documents par des liens externes, avec des CGIs par exemple.
De nombreux explorateurs s'identifient quand ils demandent un document. Un script CGI pourra accéder à cette information dans la varible d'environnement HTTP_USER_AGENT, et il pourra l'utiliser pour envoyer une version du document optimisée pour ce navigateur.
Souvenez vous que tous les navigateurs ne s'identifient pas correctement. Microsoft Internet Explorer, par exemple, prétend être "Mozilla" pour récupérer les documents améliorés pour Netscape.
De plus, en cas d'utilisation d'un serveur mandataire cache (proxy), c'est le document qui est dans le cache qui sera envoyé en cas de nouvelle requête, même si c'est un autre utilisateur avec un autre navigateur qui fait la requête...
Pour ces raisons, ça n'est pas forcément une bonne idée de jouer au jeu de "deviner le navigateur".
Vous ne pouvez pas! Bien que chaque requête pour un document soit habituellement conservée dans un fichier avec le nom ou l'adresse de l'hôte distant, l'adresse email, elle, reste inconnue du serveur qui ne peut la deviner (sauf éventuellement pour ceux ayant un serveur identd accessible, ce qui représente une infime partie des utilisateurs d'internet).
Mais prenez un peu de recul... en tant qu'utilisateur, voudriez-vous que chaque site que vous visitez puisse connaitre votre adresse de courrier électronique? Imaginez le nombre de remerciements automatiques que vous recevriez. Si vous en visitez 20, vous auriez 20 couriels par jour, sans compter les messages de réinvitation! Ce serait un cauchemard en plus d'une invasion de la vie privée.
La seule façon de faire est de créer un formulaire invitant le visiteur à laisser son adresse électronique. Pour augmenter les chances que l'utilsateur prenne vraiment cette peine, offrez-lui quelque chose d'utile en retour.
Les versions récentes d'Internet Explorer affichent par défaut un message d'erreur interne supposé plus explicatif quand la réponse HTTP est plus courte que 512 octets. En tant qu'utilisateur d'Internet Explorer, vous pouvez désactiver cette fonction dans l'onglet "Avancées" des options. En tant qu'auteur, vous n'avez pas d'autre choix que de faire la page plus longue que 512 octets.
Pour des rajouts ou des oublis dans cette FAQ, merci de contacter <darin@htmlhelp.com> (en anglais) ou <cedrik.rousseau@insa-rouen.fr> (en français)
Toutes les informations ici présentes ont été compilées à l'origine par les membres du Web Design Group, principalement Arnoud "Galactus" Engelfriet, John Pozadzides, et Darin McGrew. La traduction hollandaise de cette FAQ a été réalisée par Rijk van Geijtenbeek, tandis que la traduction française à été faite par Cédrik Rousseau dans le cadre de l'UV traduction de FAQ du département ASI de l'INSA Rouen.
Des compléments ont été apportés par Boris Ammerlaan, Martin Atkins, Lori Atwater, Alex Bell, Stan Brown, Roger Carbol, Alex Chapman, Jan Roland Eriksson, Jon Erlandson, Mark Evans, Peter Evans, Alan Flavell, Rijk van Geijtenbeek, Lucie Gelinas, Bjoern Hoehrmann, Tina Marie Holmboe, Cliff Howard, Thomas Jespersen, Peter Jones, Nick Kew, Jukka Korpela, Simon Lee, Nick Lilavois, Neal McBurnett, Glen McDonald, Dan McGarry, Ken O'Brien, Timothy Prodin, Steve Pugh, Liam Quinn, Colin Reynolds, Kai Schätzl, Doug Sheppard, Sue Sims, Toby Speight, Warren Steel, Ian Storms, Peter Thomson, Daniel Tobias, and Diane Wilson.
Merci tout le monde
Home, Reference, FAQs, Tools, Design, Feature Article, BBS, Links
Copyright © 1996-1999. All rights reserved.