• # On veut la suite !

    Posté par  (Mastodon) . Évalué à 8 (+5/-0).

    Il me tarde d'avoir le fin mot de l'histoire quand même.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # sum up of the discussion

    Posté par  . Évalué à -7 (+2/-11).

    The discussion revolves around an unusual and excessive number of HTTP GET requests to the kernel.org website, specifically a log entry that appears over 56 million times in a single day. K. Ryabitsev, the original poster, speculates that these requests are likely from a mobile application or device performing connectivity checks, as they consistently receive a 301 redirect response.

    Participants in the conversation suggest various approaches to mitigate the issue, including:

    1. Redirecting Traffic: One user proposes routing the traffic through a CDN to manage the load better.
    2. Blocking Requests: Several participants suggest blocking requests from the specific user agent (okhttp/4.9.0) or implementing timeout strategies to make the connectivity checks ineffective.
    3. Analyzing Traffic: Suggestions include using tools like Wireshark to analyze the traffic and identify the source devices or applications.
    4. Testing Responses: Some participants recommend returning different HTTP status codes (like 404 or 429) to see how the requesting applications respond, potentially leading to bug reports from users or developers.
    5. Identifying the Source: There are discussions about the possibility of this traffic being linked to a popular Android app or a botnet, with suggestions to check for patterns in the requests or to reach out to the okhttp library maintainers for insights.

    Overall, the conversation highlights the challenges of managing unexpected traffic to a website and the collaborative effort to find a solution.

    • [^] # Re: sum up of the discussion

      Posté par  . Évalué à 8 (+6/-0).

      C'est un résumé fait par IA générative je suppose ?

      Je préférerais que ça soit clairement mentionné, si c'est le cas, soit dans le titre, soit dans le commentaire lui-même :)

    • [^] # Re: sum up of the discussion

      Posté par  . Évalué à 4 (+2/-0).

      Analyzing Traffic: Suggestions include using tools like Wireshark to analyze the traffic and identify the source devices or applications.

      C'est faux, personne ne dit ça. Je cite les deux passages dans la source :

      https://ioc.exchange/@wall_e/113475409868358481
      I guess some OnePlus user on OxygenOS 14 could check with Wireshark 🤔

      https://mstdn.science/@bencardoen/113472236672739470
      @monsieuricon Perhaps OS fingerprinting with Wireshark can tell you if these are from the same device/OS or not, which could narrow things down?

    • [^] # Re: sum up of the discussion

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 13 novembre 2024 à 14:40.

      (Zut, j'avais écrit ce message avant que les autres réponses ne soient postées, il était donc obsolète au moment où je l'ai envoyé. Désolé)

      • [^] # Re: sum up of the discussion

        Posté par  . Évalué à -5 (+0/-7).

        Voici (LLM generated):

        La discussion porte sur un nombre inhabituel et excessif de requêtes HTTP GET vers le site kernel.org, avec une entrée de journal qui apparaît plus de 56 millions de fois en une seule journée. K. Ryabitsev, l'auteur du message original, suppose que ces requêtes proviennent probablement d'une application mobile ou d'un appareil effectuant des vérifications de connectivité, car elles reçoivent systématiquement une réponse de redirection 301.

        Les participants à la conversation suggèrent diverses approches pour atténuer le problème, notamment :

        1. Rediriger le trafic : Un utilisateur propose de faire passer le trafic par un CDN pour mieux gérer la charge.
        2. Bloquer les requêtes : Plusieurs participants suggèrent de bloquer les requêtes provenant de l'agent utilisateur spécifique (okhttp/4.9.0) ou de mettre en œuvre des stratégies de délai d'attente pour rendre les vérifications de connectivité inefficaces.
        3. Analyser le trafic : Des suggestions incluent l'utilisation d'outils comme Wireshark pour analyser le trafic et identifier les appareils ou applications sources.
        4. Tester les réponses : Certains participants recommandent de renvoyer différents codes de statut HTTP (comme 404 ou 429) pour voir comment les applications demandeuses réagissent, ce qui pourrait potentiellement conduire à des rapports de bogues de la part des utilisateurs ou des développeurs.
        5. Identifier la source : Il y a des discussions sur la possibilité que ce trafic soit lié à une application Android populaire ou à un botnet, avec des suggestions de vérifier les modèles dans les requêtes ou de contacter les mainteneurs de la bibliothèque okhttp pour obtenir des informations.

        Dans l'ensemble, la conversation met en lumière les défis de la gestion d'un trafic inattendu vers un site web et l'effort collaboratif pour trouver une solution.

      • [^] # Re: sum up of the discussion

        Posté par  . Évalué à 2 (+1/-1).

        On est d'accord que ton message demandait une versions FR ?
        Normalement, j'aurai pas pu y répondre ou tu n'aurais pas du pouvoir le modifier. Un bug/feature du site ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.