[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: OCS Providers File - High Numbers of Requests
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2021-09-27 9:23:18
Message-ID: CA+XidOEM23f-zz8ESBcbf2DVDqXejNTFB23B+5VxJdMN1RaLWg () mail ! gmail ! com
[Download RAW message or body]

On Mon, Sep 27, 2021 at 7:04 AM Aleix Pol <aleixpol@kde.org> wrote:

> On Fri, Sep 24, 2021 at 8:26 PM Ben Cooksley <bcooksley@kde.org> wrote:
> >
> > On Sat, Sep 25, 2021 at 12:34 AM Aleix Pol <aleixpol@kde.org> wrote:
> >>
> >> On Fri, Sep 24, 2021 at 1:32 AM Nicol=C3=A1s Alvarez
> >> <nicolas.alvarez@gmail.com> wrote:
> >> >
> >> > El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleixpol@kde.or=
g)
> escribi=C3=B3:
> >> > >
> >> > > On Thu, Sep 23, 2021 at 10:12 PM Nicol=C3=A1s Alvarez
> >> > > <nicolas.alvarez@gmail.com> wrote:
> >> > > >
> >> > > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (
> aleixpol@kde.org) escribi=C3=B3:
> >> > > > >
> >> > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley <
> bcooksley@kde.org> wrote:
> >> > > > > >
> >> > > > > > Hi all,
> >> > > > > >
> >> > > > > > It has recently come to our attention that the number of
> queries being handled for the endpoint
> https://autoconfig.kde.org/ocs/providers.xml on a day to day basis has
> gotten to the point where it is causing issues with server responsiveness
> to other traffic. This is perhaps best summarised by the following:
> >> > > > > >
> >> > > > > > root@nicoda /var/log/apache2 # ls -lah ...
> >> > > > > > -rw-r----- 1 root adm 458M Sep 23 06:25
> autoconfig.kde.org.log.1
> >> > > > > > -rw-r----- 1 root adm 381M Sep 23 06:25
> networkcheck.kde.org.log.1
> >> > > > > > -rw-r----- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> >> > > > > >
> >> > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1
> | wc -l
> >> > > > > > 4,222,343
> >> > > > > >
> >> > > > > > Based on those numbers we're looking at 48-49 requests per
> second (on average - peaks are much higher by many magnitudes), which see=
ms
> extremely excessive given that this file is only supposed to be retrieved
> by KDE software when GHNS functionality is triggered. That is supported b=
y
> the substantial size difference it has over networkcheck.kde.org - which
> is used by plasma-nm and NetworkManager (on Neon) to check for whether th=
ey
> have a working internet connection - which i'd expect to be the site
> receiving the most traffic.
> >> > > > > >
> >> > > > > > As such, I therefore suspect we have bug(s) in software that
> makes use of GHNS functionality.
> >> > > > > >
> >> > > > > > It would therefore be appreciated if we could please review
> the software in question to determine whether it is operating correctly.
> Given that it usually runs in the background on user systems, i'd
> especially appreciate it if a detailed review could be conducted on
> Discover and other software that conducts package management operations o=
r
> assists in managing updates.
> >> > > > > >
> >> > > > > > Unfortunately all these applications submit a fairly useless
> user agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain an=
y
> further information. If we could get information on the software that is
> originating the request added to the user agent to assist in investigatin=
g
> these issues in the future that would be extremely helpful.
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Ben
> >> > > > >
> >> > > > > That's correct. Discover fetches them at startup. It's
> necessary to be
> >> > > > > able to check if there are updates on KNS-provided resources.
> >> > > > >
> >> > > > > Incidentally,  I was looking into this yesterday incidentally.
> We
> >> > > > > could see if caching is broken somehow. A request will still b=
e
> needed
> >> > > > > though to check if the cache is out of date.
> >> > > >
> >> > > > Caching seems to be working, since the vast majority of the
> requests
> >> > > > are returning 304 Not Modified.
> >> > > >
> >> > > > However in *many* cases I see a single IP making multiple
> requests in
> >> > > > the same second, and doing it again the next minute. Here's one =
IP
> >> > > > address picked randomly:
> >> > > >
> >> > > > [22/Sep/2021:06:25:41 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:25:41 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:25:41 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:25:41 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:27:57 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:27:58 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:27:58 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:32 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:32 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:32 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:32 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:59 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:59 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:59 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:28:59 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:30:11 +0000] "GET /ocs/providers.xml HTTP/1.1" 2=
00
> >> > > > [22/Sep/2021:06:30:11 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:30:11 +0000] "GET /ocs/providers.xml HTTP/1.1" 2=
00
> >> > > > [22/Sep/2021:06:30:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:30:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:30:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:30:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:19 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:19 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:19 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:19 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > > [22/Sep/2021:06:31:38 +0000] "GET /ocs/providers.xml HTTP/1.1" 3=
04
> >> > > >
> >> > > > This continues for hours. And it's not an isolated case; again,
> the IP
> >> > > > I searched for was a random one from the log.
> >> > > >
> >> > > > There are 120 IP addresses that *each* made more than 10,000
> requests
> >> > > > in a 24h period.
> >> > > >
> >> > > > I tried a few GHNS things on my own system and I couldn't
> reproduce it...
> >> > > >
> >> > > > --
> >> > > > Nicol=C3=A1s
> >> > >
> >> > > Is there a possibilty that we can get an UserAgent of something li=
ke
> >> > > that to see who's asking?
> >> >
> >> > Yes please :P
> >> >
> >> > (all requests to this file currently have "Mozilla/5.0" as the
> >> > User-Agent, I very much welcome modifying the code so that it sends
> >> > something useful instead)
> >> >
> >> > --
> >> > Nicol=C3=A1s
> >>
> >> This is for KNS:
> >> https://invent.kde.org/frameworks/knewstuff/-/merge_requests/142
> >>
> >> Attica already sets the UserAgent.
> >
> >
> > Thanks for getting all of these changes through.
> > Hopefully in the coming months we'll start to see the impact of these
> changes.
> >
> > In the meantime, we've switched autoconfig.kde.org to our CDN provider,
> which should enable our systems to continue to handle the current load
> we're experiencing.
>
> Ok, thank you. Please reach out as soon as you see where these
> requests are coming from.
>

Will do - we'll need to give it a little while for the fixes to make it out
to users, after which we'll be able to start looking into this.
Server wise CDN77 is handling the bulk of requests now fortunately.


> Aleix
>

Cheers,
Ben

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep \
27, 2021 at 7:04 AM Aleix Pol &lt;<a \
href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Fri, Sep 24, 2021 at 8:26 PM Ben Cooksley \
&lt;<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>&gt; \
wrote:<br> &gt;<br>
&gt; On Sat, Sep 25, 2021 at 12:34 AM Aleix Pol &lt;<a href="mailto:aleixpol@kde.org" \
target="_blank">aleixpol@kde.org</a>&gt; wrote:<br> &gt;&gt;<br>
&gt;&gt; On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez<br>
&gt;&gt; &lt;<a href="mailto:nicolas.alvarez@gmail.com" \
target="_blank">nicolas.alvarez@gmail.com</a>&gt; wrote:<br> &gt;&gt; &gt;<br>
&gt;&gt; &gt; El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (<a \
href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>) escribió:<br> \
&gt;&gt; &gt; &gt;<br> &gt;&gt; &gt; &gt; On Thu, Sep 23, 2021 at 10:12 PM Nicolás \
Alvarez<br> &gt;&gt; &gt; &gt; &lt;<a href="mailto:nicolas.alvarez@gmail.com" \
target="_blank">nicolas.alvarez@gmail.com</a>&gt; wrote:<br> &gt;&gt; &gt; &gt; \
&gt;<br> &gt;&gt; &gt; &gt; &gt; El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol \
(<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>) \
escribió:<br> &gt;&gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley &lt;<a \
href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>&gt; wrote:<br> \
&gt;&gt; &gt; &gt; &gt; &gt; &gt;<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt; Hi all,<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt; It has recently come to our attention that the \
number of queries being handled for the endpoint <a \
href="https://autoconfig.kde.org/ocs/providers.xml" rel="noreferrer" \
target="_blank">https://autoconfig.kde.org/ocs/providers.xml</a> on a day to day \
basis has gotten to the point where it is causing issues with server responsiveness \
to other traffic. This is perhaps best summarised by the following:<br> &gt;&gt; &gt; \
&gt; &gt; &gt; &gt;<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt; root@nicoda \
/var/log/apache2 # ls -lah ...<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt; -rw-r----- 1 \
root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1<br> &gt;&gt; &gt; &gt; &gt; &gt; \
&gt; -rw-r----- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1<br> &gt;&gt; \
&gt; &gt; &gt; &gt; &gt; -rw-r----- 1 root adm 143M Sep 23 06:25 \
www.kde.org.log.1<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt; root@nicoda /var/log/apache2 # cat \
autoconfig.kde.org.log.1 | wc -l<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt; 4,222,343<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt; Based on those numbers we&#39;re looking at 48-49 \
requests per second (on average - peaks are much higher by many magnitudes), which \
seems extremely excessive given that this file is only supposed to be retrieved by \
KDE software when GHNS functionality is triggered. That is supported by the \
substantial size difference it has over <a href="http://networkcheck.kde.org" \
rel="noreferrer" target="_blank">networkcheck.kde.org</a> - which is used by \
plasma-nm and NetworkManager (on Neon) to check for whether they have a working \
internet connection - which i&#39;d expect to be the site receiving the most \
traffic.<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt; As such, I therefore suspect we have bug(s) in \
software that makes use of GHNS functionality.<br> &gt;&gt; &gt; &gt; &gt; &gt; \
&gt;<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt; It would therefore be appreciated if we \
could please review the software in question to determine whether it is operating \
correctly. Given that it usually runs in the background on user systems, i&#39;d \
especially appreciate it if a detailed review could be conducted on Discover and \
other software that conducts package management operations or assists in managing \
updates.<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt; Unfortunately all these applications submit a \
fairly useless user agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain \
any further information. If we could get information on the software that is \
originating the request added to the user agent to assist in investigating these \
issues in the future that would be extremely helpful.<br> &gt;&gt; &gt; &gt; &gt; \
&gt; &gt;<br> &gt;&gt; &gt; &gt; &gt; &gt; &gt; Thanks,<br>
&gt;&gt; &gt; &gt; &gt; &gt; &gt; Ben<br>
&gt;&gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; That&#39;s correct. Discover fetches them at startup. \
It&#39;s necessary to be<br> &gt;&gt; &gt; &gt; &gt; &gt; able to check if there are \
updates on KNS-provided resources.<br> &gt;&gt; &gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; &gt; Incidentally,   I was looking into this yesterday \
incidentally. We<br> &gt;&gt; &gt; &gt; &gt; &gt; could see if caching is broken \
somehow. A request will still be needed<br> &gt;&gt; &gt; &gt; &gt; &gt; though to \
check if the cache is out of date.<br> &gt;&gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; Caching seems to be working, since the vast majority of the \
requests<br> &gt;&gt; &gt; &gt; &gt; are returning 304 Not Modified.<br>
&gt;&gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; However in *many* cases I see a single IP making multiple \
requests in<br> &gt;&gt; &gt; &gt; &gt; the same second, and doing it again the next \
minute. Here&#39;s one IP<br> &gt;&gt; &gt; &gt; &gt; address picked randomly:<br>
&gt;&gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:25:41 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:25:41 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:25:41 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:25:41 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:27:57 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:27:58 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:27:58 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:28:32 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:28:32 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:28:32 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:28:32 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:28:59 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:28:59 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:28:59 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:28:59 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:30:11 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 200<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:30:11 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:30:11 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 200<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:30:38 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:30:38 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:30:38 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:30:38 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:31:19 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:31:19 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:31:19 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:31:19 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:31:38 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:31:38 +0000] &quot;GET /ocs/providers.xml \
HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; [22/Sep/2021:06:31:38 +0000] &quot;GET \
/ocs/providers.xml HTTP/1.1&quot; 304<br> &gt;&gt; &gt; &gt; &gt; \
[22/Sep/2021:06:31:38 +0000] &quot;GET /ocs/providers.xml HTTP/1.1&quot; 304<br> \
&gt;&gt; &gt; &gt; &gt;<br> &gt;&gt; &gt; &gt; &gt; This continues for hours. And \
it&#39;s not an isolated case; again, the IP<br> &gt;&gt; &gt; &gt; &gt; I searched \
for was a random one from the log.<br> &gt;&gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; There are 120 IP addresses that *each* made more than 10,000 \
requests<br> &gt;&gt; &gt; &gt; &gt; in a 24h period.<br>
&gt;&gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; I tried a few GHNS things on my own system and I couldn&#39;t \
reproduce it...<br> &gt;&gt; &gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; --<br>
&gt;&gt; &gt; &gt; &gt; Nicolás<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Is there a possibilty that we can get an UserAgent of something \
like<br> &gt;&gt; &gt; &gt; that to see who&#39;s asking?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes please :P<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; (all requests to this file currently have &quot;Mozilla/5.0&quot; as \
the<br> &gt;&gt; &gt; User-Agent, I very much welcome modifying the code so that it \
sends<br> &gt;&gt; &gt; something useful instead)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Nicolás<br>
&gt;&gt;<br>
&gt;&gt; This is for KNS:<br>
&gt;&gt; <a href="https://invent.kde.org/frameworks/knewstuff/-/merge_requests/142" \
rel="noreferrer" target="_blank">https://invent.kde.org/frameworks/knewstuff/-/merge_requests/142</a><br>
 &gt;&gt;<br>
&gt;&gt; Attica already sets the UserAgent.<br>
&gt;<br>
&gt;<br>
&gt; Thanks for getting all of these changes through.<br>
&gt; Hopefully in the coming months we&#39;ll start to see the impact of these \
changes.<br> &gt;<br>
&gt; In the meantime, we&#39;ve switched <a href="http://autoconfig.kde.org" \
rel="noreferrer" target="_blank">autoconfig.kde.org</a> to our CDN provider, which \
should enable our systems to continue to handle the current load we&#39;re \
experiencing.<br> <br>
Ok, thank you. Please reach out as soon as you see where these<br>
requests are coming from.<br></blockquote><div><br></div><div>Will do - we&#39;ll \
need to give it a little while for the fixes to make it out to users, after which \
we&#39;ll be able to start looking into this.</div><div>Server wise CDN77 is handling \
the bulk of requests now fortunately.<br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Aleix<br></blockquote><div><br></div><div>Cheers,</div><div>Ben<br></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic