Accueil - Référencement de site - url étrange générée sur un serveur OVH

Vous avez aimé cet article ? Alors partagez-le avec vos amis en cliquant sur les boutons ci-dessous :

url étrange générée sur un serveur OVH

Un site refait et hébergé chez OVH, pose problème à cause de l'apparation d'url plus qu'étrange ... Recherche de solution pour le codage et le référencement. Lors de la refonte du site mariagemovies.com, grosse surprise ; l'apparition par moments d'urls étranges, genre "session", sur un hébergement OVH semble aussi liée à la mauvaise prise en compte du site par les boots des moteurs et freiner son référencement.

Le script utilisé, un petit CMS 'maison', qui tourne sans aucun problèmes chez plusieurs hébergeurs ne peut pas être en cause ... et pourtant sur ce site je rencontre des liens comme celui-ci: http://www.mariagemovies.com/thierry-sarraute-videaste-professionnel.php?PHPSESSID=2d578b782fdf2944b9fd7dd17b50fc8b alors que le lien normal est bien : http://www.mariagemovies.com/thierry-sarraute-videaste-professionnel.php !!!

Un SOS lancé sur les forum de commençamarche et de webrankinfo m'en a appris bien d'autres : ce n'est pas la première fois que cela arrive et il n'y a que deux solutions finalement.

- intervenir dans le code source (php) en mettant ceci : ini_set('session.use_cookies', '1'); ini_set('session.use_only_cookies', '1'); // PHP >= 4.3 ini_set('session.use_trans_sid', '0'); ini_set('url_rewriter.tags', ''); session_start(); à mettre dans toutes les pages ...

- se servir du fichier .htaccess en mettant ceci : SetEnv SESSION_USE_TRANS_SID 0 (à noter que si l'on fait une recherche sur cette ligne dans google, l'on tombe sur la FAQ d'OVH parmi les réponses ...)

Ne voyant pas pourquoi je serai obligé de revoir le codage PHP d'un script qui tourne correctement ailleurs, j'ai donc utilisé la deuxième solution qui semble porter ses fruits ...

Mais pourquoi donc être obligé de faire de telles manipulations pour mettre son site sur un hébergement que l'on paie ? Un hébergement sur lequel ce genre de problème a l'air d'être courant depuis ... quelques années !

Si cette question vous concerne ou vous intéresse, vous pouvez y répondre dans les commentaires ci-dessous et peut-être aussi qu'un jour quelqu'un de che OVH nous fera le plaisir de nous donner une explication concrète ou de nous dire que le problème n'existe plus ...

 

 

Tous les articles de blog, ainsi que leur contenu, comme indiqué en page index du site principal, sont mis à disposition sous les termes de la licence Creative Commons. Vous pouvez le copier, distribuer et modifier tant que cette note apparaît clairement. " source: longuetraine.fr - Paternité - Pas d'Utilisation Commerciale - Partage des Conditions Initiales à l'Identique 3.0 France ", ainsi qu'un lien vers la source .
à voir également :

5 commentaires

#1  - GC a dit :

ce type d'url sert a stockée ou reconnaitre une session, par defaut les session sont stockées dans les cookies si possible , ceux ci n'etant pas 100% fiable selon le navigateur et sa configuration il ne reste plus qu'a les passé via l'url .

En principe , le site devrait tester si les cookies sont utilisables avant d'imposer ce type d'url et s'en servir uniquement quand il y en a besoin.

GC

#2  - coucou a dit :

autre solution, surtout pour le codage en php:
ini_set('session.use_cookies', '1');
ini_set('session.use_only_cookies', '1'); // PHP >= 4.3
ini_set('session.use_trans_sid', '0');
ini_set('url_rewriter.tags', '');
session_start();

à injecter sur toutes les pages de ton site avant quoi que ce soit... Moi c'est comme ça que je fais.

#3  - doob a dit :

je me permets : vous posez étrangement votre problème et mettez en cause OVH injustement (facile de taper sur l'hébergeur). si votre site utilise des sessions, celles-ci peuvent être maintenues soit par cookie, soit en passant le paramètre PHPSESSID dans l'URL. en l'absence de support de cookie par l'utilisateur (navigateur ou robot), la 2ème option est automatiquement utilisée et le serveur aura fait son travail. comme vous l'indiquez vous-même vous pouvez utiliser "SetEnv SESSION_USE_TRANS_SID 0" pour interdire ce dernier comportement, avec l'avantage d'URLs propres pour les robots et l'inconvénient de perdre les sessions pour les utilisateurs ne supportant pas les cookies. à vous de choisir, mais ne criez pas en méconnaissance de cause..!

#4  - unesourisetmoi a dit :

@doob : je ne 'tape' pas sur l'hébergeur, je râle en moi-même pour le temps perdu à chercher des solutions correctes fonctionnant chez celui-ci, alors que dans la grande majorité des cas il n'y a rien de spécial à faire ... ce problème semblant récurant chez ovh, pourquoi ne le corrigent-ils pas, ou n'avertissent-ils pas très clairement leurs clients, surtout la grande majotité qui ne connait pas grand chose en programmation, ne s'en rendant parfois même pas compte et ce qui les entraîne souvent à lancer des "sos" sur certains forums d'entraide ... Tous les abonnés d'un hébergeur ne sont pas forcément des as de la programmation alors pourquoi leur freiner ainsi la possibilité d'une bonne accessibilité de leur site à un référencement correcte ? un peu normal, non ? c'est pour moi la 'petite' réaction de base de "monsieur tout le monde" ...

#5  - wallpapers free a dit :

la solution :
Essaye en mettant "SetEnv SESSION_USE_TRANS_SID 0" dans ton .htaccess
sans les "
Je suis aussi chez OVH et je n'ai pas ce problème avec Wordpress.
fonctionne
merci à avionf16

Fil RSS des commentaires de cet article

Écrire un commentaire

Quelle est la deuxième lettre du mot nday ?

Pour laisser un petit avis au passage, nul besoin d'avoir un site ou une adresse Internet, juste se donner un 'pseudo' ...
Les commentaires sont en 'dofollow', mais modérés à priori. Ils ne seront publiés qu'après vérification de votre message.
Si vous pensez ou désirez obtenir un backlink, votre commentaire doit être construit de manière cohérente, rédigé correctement ET avoir un minimum de contenu et de pertinence.