kriss

oui, "../" remonte bien au dossier parent donc "../images" remonte au dossier parent puis redescend dans le dossier frère/soeur "images".

Dans la structure arborescente d'un site, l'adressage relatif d'un document situé dans un répertoire du même niveau est censé être effectué de la manière suivante : "../images/image.gif". Cela a toujours posé des problèmes à quelques robots mais depuis quelques mois, il semble que notre ami FaceBook ne parvienne pas à gérer correctement l'adressage relatif ce qui a pour effet de poluer nos logs d'erreurs avec des messages du type : "Invalid URI in request GET /../images/image.gif HTTP/1.1". Une réécriture d'url consistant à ôter les deux points ".." précédant les requêtes invalides permettrait de résoudre le problème. Cela me semble moins lourd que de transformer tous les adressages relatifs du site (plusieurs dizaines de milliers) en adressages absolus. Qu'en pensez-vous ? D'avance, merci pour vos commentaires. Kriss.

"L'existence d'un contrat de travail n'emporte aucune dérogation à la jouissance des droits d'auteur qui naissent sur la tête du salarié même si l'oeuvre est créée en exécution des directives de l'employeur" TGI de LYON, ordonnance du 22 oct. 2001. Même en l'absence d'un contrat de travail, une activité régulière au sein d'une association au titre de "webmaster" entre dans ce cas. ATTENTION, Dans le terme "Droit d'Auteur", il y a lieu de distinguer les droits patrimoniaux des droits moraux. En effet, un employeur reste détenteur des droits patrimoniaux attachés à une oeuvre créée par l'un de ses employés dans le cadre de son contrat de travail. Toutefois l'employé reste détenteur des droits moraux attachés à son oeuvre, y-compris après la fin du contrat de travail. Les droits moraux n'autorisent pas l'auteur à revendiquer le versement de droits d'auteur mais autorisent celui-ci à exercer un droit de regard sur l'utilisation faite de son oeuvre. Celle-ci ne doit pas être détournée, modifiée, dégradée, etc... Dans ce cas, tout est une affaire de degré et reste à l'appréciation des Juges. Kriss.

Bonsoir Pat. Il juridiquement très délicat d'évoquer nos cas de jurisprudence sur nos sites. En général les cas de jurisprudence ne peuvent être rapportés que par les organes de presse (avec certaines réserves), les sites d'informations (ex. juridiques), ou bien publiés d'autorité sur décision de Justice. En dehors de ce cadre strict, utiliser de la jurisprudence sur un site commercial est risqué. En effet, au moins une des deux parties concernées ne sera jamais d'accord, la publication d'une jurisprudence "anonymisée" peut jeter le doute sur l'authenticité de la jurisprudence publiée, etc... C'est un pas que (pour l'instant) nous avons décidé de ne pas franchir... Kriss.

Bonsoir Arlette. Je lis toujours avec intérêt les posts du Hub mais cela faisait longtemps que je n'avais pas posté sur un sujet qui nous concerne... ConstatOnline a bien un lien avec CopyrightFrance. En matière de Constats sur Internet la compétence territoriale des Huissiers de Justice ne s'applique pas. Nous connaissons (très) bien la jurisprudence que tu évoques. Sans rentrer dans des détails technico/juridiques, il se trouve que nos Procès-Verbaux de Constat d'Huissier comportaient chacun deux pièces dont une (capitale puisque son absence a provoqué l'invalidation) n'a tout simplement pas été communiquée au Tribunal (ou au moins exploitée) par le défenseur de notre client. L'affaire a donc été jugée sur trois "demi-constats". Cette grosse bévue aurait immédiatement été corrigée en appel mais aucune des parties n'a jugé utile de faire appel de la décision du Tribunal. En tout état de cause, nous avons maintenant modifié notre procédure afin d'empêcher définitivement qu'une partie de nos pièces soit ignorée par les Tribunaux. Kriss.

Oui, euhh... Les précisions, c'était juste pour que quelqu'un comme moi, c'est à dire un non spécialiste qui ferait une recherche sur ce thème puisse lire une question précise (et bien entendu la réponse apportée par le spécialiste). Merci.

Merci Dan ! Oui, c'est pour cela que je précise "maboutique.com/produit.php?type=baladeur&marque=sony (requête réelle qui doit être envoyée en interne au serveur Apache)" D'ailleurs dans mon premier exemple (l'exemple "bateau"), l'url refabriquée avec l'extension .htm n'existe pas non plus pour le serveur apache, et pourtant, il l'affiche sur le navigateur alors qu'en réalité, il traite en interne la requête complète (maboutique.com/produit.php?type=baladeur&marque=sony).

Bonsoir. Grosse panne d'inspiration à propos des réécritures d'urls... réécrire : maboutique.com/produit.php?type=baladeur&marque=sony en : maboutique.com/baladeur-sony.htm ne pose à priori pas de problèmes. Mais réécrire : maboutique.com/produit.php?type=baladeur&marque=sony (requête réelle qui doit être envoyée en interne au serveur Apache) en : maboutique.com/produit.php (url "retravaillée" qui doit être affichée sur le navigateur de l'utilisateur) Me semble insurmontable bien que j'ai crû comprendre que la chose était possible... Si quelqu'un voit une solution (ou une impossibilité rédhibitoire), je l'en remercie d'avance.

Idem chez moi... Très impressionnant ! Au début je me suis cru infecté par "Antivirus 2009" qui produit à peu près ce genre de choses. Ca va cliquer fort sur les liens Adwords (les seuls qui fonctionnent encore).

Pour retirer le slash en fin de nom de fichier, la règle suivante semble bien fonctionner : RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.+)/$ /$1 [R=301,L] Avec une petite redirection 301, histoire que les robots n'y reviennent pas trop... Ca peut économiser quelques tonnes d'erreurs 404 dans les logs, et l'air de rien, beaucoup de sites sont mal protégés contre cette habitude de mettre un slash en fin d'url.

Merci Dan ! C'est beaucoup mieux car seules les url vraiment valides fonctionnent (un gros progrès). Par-contre en cas d'urls terminées par un slash : h*tp://www.toto.com/pages/ h*tp://www.toto.com/pages/accueil.php/ Apache tente de remonter à : /home/toto/webpages/home ( pour info, mon DocumentRoot est : /home/toto/webpages ) étrange non ?

Merci Dan ! J'essaye de ce pas !

La solution php est effectivement très intéressante dans le cas ou Apache ne saurait pas le faire...

Bonsoir. Lorsqu'elles veulent citer une url ou établir un lien vers une page, beaucoup de personnes ajoutent un slash en fin d'url... Lors de l'accès à l'url en question, cela provoque souvent une belle pagaille car tous les adressages relatifs contenus dans la page sont perdus... Existe t-il un moyen (url rewriting, conf d'Apache, ...?) qui permettrait, à l'arrivée de supprimer ces slashes inutiles en fin d'url ? Merci.

Oui, enfin, comme le disait Dadou en début de conversation, ces deux hébergeurs sont réellement dépourvus de support. Le support d'OVH, bien que théoriquement présent n'est en aucun cas adapté à une clientèle "pro" (qualité, délais, etc...). C'est d'ailleurs probablement la raison pour laquelle OVH vient d'annoncer une nouvelle politique "orientée pro" (il était vraiment temps...).