Pb de configuration serveur ?

Meme probleme sur smartphone et tablet.
La page d’accueil hisse-et-oh.com/ est en faute car si l’on passe par une page interne directement (bookmarquée ou historique) le problème n'existe plus.

Idem, Firefox et Xubuntu, en page interne, aucun problème lorsqu'on est déjà sur l'un des onglets.
Il m'est arrivé d'avoir des blocages inexpliqués alors que mon bookmark Firefox est www.hisse-et-oh.com[...]okmarks

06:50 UTC-4 ce matin, même symptôme = ticket non clos

Philippe

Rien à voir avec la pub, c'est une erreur classique sur serveur web. Ça peut venir de plein de choses, pb d'adressage, de droits, de lien symbolique, problème de synchro, d'une page en train d'être déménagée,...
N'oublions pas que le passage à la nouvelle version est toujours en cours (on ne bouge pas autant de pages par magie), et que c'est l'été et que chez en plus chez ovh c'est des chèvres...;-)
Mais cela n'a en tout ça rien à voir avec du racisme anti Linux(ça la foutrait mal pour un serveur web), ni anti bloqueur de pub.

Pour la 2e fois, les erreurs 500 sont des erreurs au niveau du serveur, pas du client. Le problème ne vient pas de la configuration de votre PC.

Bonsoir
Je suis chez OVH depuis très longtemps et pour de nombreux sites (B2B) hébergés en mutualisé ou dédié et développés en PHP/MySql ou utilisant des CMS et je n’ai jamais eu ce genre de message, des erreurs 500 oui, mais pas de ce type.
Des plantages oui quand il y avait des bugs dans les scripts ou des plantages généraux d’OVH (que l’on retrouvait par ex sur downdetector)...
C’est toujours très difficile de trouver des plantages intermittents, bonne chance !
Peut être une première approche pourrait être de mettre sous surveillance automatique (monitoring) la page .index ou .default pour avoir une idée de l’occurence du problème.

j'ai ça depuis des mois et de mémoire depuis la v5 et jamais avant.

Met avis que c'est plus un soucis d'affinité lié au load balancing que le load balancing lui même.

C'est quoi le mode de distribution ? Le tracking semble par cookie avec aucune date d'expiration, ça explique pourquoi ils ont ce soucis depuis des mois... il suffit au pire d'effacer le cookie "SERVERID" pour corriger (temporairement) le soucis.

Sauf si tu es en round robin ou hashage d’URI (celui la est rare), il y a toujours un cookie de tracking (et non de session) mise à part si tu fais du stickyless (et non ness).

Vu que tu le site ne redemandes pas d’authentification à chaque page tu as forcément une session. Soit par un cookie de session, un SID dans l’URL, de l’evercooking, du LSO (les deux derniers étant ultra ultra ultra rare).

Sauf si tu a un service spécifique pour partager les états de sessions entre serveur, tu es obligé de faire du stickyness.

Je suis sur mon téléphone au moment où je rédige ce message. Mais vu que je ne vois pas de SID, j’aurais tendance à penser qu’il y a un cookie de session ET un cookie de tracking.

Si c’est le cas l’erreur est certainement lié à un soucis d’affinité si l’état s’est perdu à un moment donné.

Si c’est le cas ce n’est pas un gros bug, il suffit de regarder où il se crée dans les logs (généralement au moment de la vérification des droits de l’utilisateur).

Attention par contre le load balancing qu’il soit en niveau 2 ou 7 se fait à la connexion ce n’est pas un réel équilibrage du traffic (au sens volumétrie de bande passante utilisée). D’autres parts de nombreux paramètres jouent dans la configuration d’Apache dans le mode (prefork / worker) utilisé.

Détail un peu plus. Je ne comprends par ce que tu veux dire.

Quand tu as mécanisme de load balancing, tu as d’abord un frontend qui écoute sur un port donné (ici du TCP/443).

Son rôle est d’équilibrer la charge sur un ensemble de serveur et de vérifier éventuellement leur état.

Quand un client, se connecte pour la première fois sur le port écouté, il tombe sur le frontend. Celui-ci regarde en premier lieu le mode de répartition qui est configuré.

Il y en a de nombreux mais les plus fréquents sont le round robin, le first, le least et le source.

Le round robin est simplement un mécanisme aléatoire. Si tu as 3 serveurs, il va envoyer les requêtes au hasard sur l’un d’eux. Aucune question ne se pose sur la charge éventuelle de l’un des noeuds.

Le first va prendre le premier serveur disponible. C’est donc plus un mécanisme de tolérance de panne que de gestion de charge.

Le least va compter le nombre de connexion actives et va envoyer la charge sur le serveur le moins actif. C’est généralement via pour du streaming ou des services avec des sessions longues.

Enfin le source utilise l’IP pour définir le serveur de destination. L’inconvénient c’est que tu tomberas toujours sur le même serveur.

Le plus simple c’est de faire du round robin.

Par contre si un serveur est HS et qu’aucune sonde n’est déclarée les requêtes tomberont systématiquement sur le serveur même en panne. Ce soucis est identique avec tous les modes, il faut donc déclarer des sondes pour « interdire » au frontend d’envoyer du traffic vers un noeud en panne.

Une fois que tes requêtes arrivent sur un serveur, celui-ci (via un langage tel que PHP, python, dotnet, etc.) va générer un id de session qui sera renvoyée au navigateur (le cookie de session).

Cette session permet au navigateur de reconnaître le client à ses prochaines demandes (une page HTML, des ressources JS, CSS, images, etc.) et de conserver des états.

A chaque fois que le navigateur effectue une demande, il renvoie les cookies dans ses entêtes, le serveur fait ensuite la correspondance avec la valeur qu’il a.

Ce qui amène au tracking. Vu que le serveur et le navigateur partage cet id de session, il faut que l’on puisse à chaque requête retourner vers le même serveur.

Pour ça tu as plusieurs solutions.

Soit par IP. Il utilise l’adresse IP de la connexion internet distante de manière générale) pour savoir si il a déjà « vu » des requêtes de passées.

Soit par cookie de tracking. Auquel cas, l’id du serveur précédemment utilisé est renvoyé par le frontend, stocké en cookie et renvoyé dans les entêtes à chaque requête.

Le fait d’effectuer le tracking par cookie est plus pertinent. Car derrière une IP tu peux avoir un nombre conséquent de périphériques.

Ce suivi que l’on nomme « affinité » permet de conditionner le mode de répartition.

Imaginons maintenant que tu as du round robin et un tracking par cookie.

Tu te connectes la première fois. Tu as 3 serveur. Le round robin t’envoi sur le noeud 2. Le serveur 2 reçoit la requête et crée un id session que l’on va nommé S2. Il renvoi une ressource (ex. une page HTML) et renvoi dans les entêtes le numéro de session (S2) et le id du serveur (2).

Tu te connectes une seconde fois (ou tu obtiens une autre ressource). L’ID de session et de tracking est envoyé. Par l’id de tracking, le frontend sait qu’il doit envoyer vers le serveur 2. Sauf que celui-ci est en panne. Il t’envoi donc vers le 3. Sauf que l’ID de session S2 ça lui parle pas donc bug.

Autre possibilité. Tu connectes normalement sur le serveur 2 mais sauf que l’ID de session n’existe plus. A nouveau bug.

Bon normalement à chaque fois qu’un ID de session n’existe pas un nouveau est créé faut il que le code y soit.

Merci pour ces infos claires.
Par contre l'intéressé ne se montre pas. Tom serait en vacances ?