openSUSE admin

FWDing this to opensuse person in charge of mirrors, as richard brown
told me this was the address to forward mirror problems to.

I received an email from someone at kernel.org claiming no prob, but
since I complained they may drop opensuse (!!!), I explained the problem
-- they are violating the Web RFC's and that their violations have nothing
to do with opensuse's mirror use, would apply to any mirror usage
going through kernel.org's mirror system (because they overload 301
to use to permanently upgrade a page, but if part of a mirror chain,
they need to use 302 as a response code).

-------- Original Message --------
Subject: Re: [sysadmin] problem with bumps to https disabling
open-source + mirrors
Date: Mon, 27 Sep 2021 19:27:12 -0700
From: L A Walsh lkml@tlinx.org
To: Konstantin Ryabitsev konstantin@linuxfoundation.org
CC: webmaster@kernel.org, ftpadmin@kernel.org
References:
DM6PR04MB479652B1C6C9CA7C93B7CC0386A39@DM6PR04MB4796.namprd04.prod.outlook.com
614EEF10.9090507@tlinx.org
20210927191507.gwf7djkvs46knq3h@meerkat.local

On 2021/09/27 12:15, Konstantin Ryabitsev wrote:

On Sat, Sep 25, 2021 at 02:42:40AM -0700, L A Walsh wrote:

Please stop the https upgrades, because when they fail, open source becomes closed source.

I appreciate your concerns, but upgrading a connection from http to https does not result in "open source" becoming "closed source".

---

It does result in terminating a mirror search that was otherwise
started with 'http'. Breaking the mirror system is specifically
the part I am referring to (see below). There are other issues
I've personally had, regarding clients that were too old to work with
upgraded https, but please regard that as a separate topic.
That said, we will probably drop opensuse from our mirrors,
as they have been a continued source of mirroring issues. In a sense, this will fix your problem because we'll return 404 before an
upgrade to https -- if I understood your description of the problem correctly.

---

First the symptom:

As my (squid) proxy stepped through the mirrors, it received a
Web Response 302 == Found and is temporarily under a
different URI. [RFC 7231 6.2.3].

At, the edge of the kernel-mirror system, (
http://sfo.korg-mirror.kernel.org), the proxy is receiving a
301 response (Moved_Permanently) referring the proxy to
the server @ https://mirrors.edge.kernel.org. The
301 response provides the new permanent address to use
for the URI

[RFC7231:6.4.2 says:]
The server "SHOULD" generate a new location header that contains
the new "preferred URI reference for the permanent URI". "The user
agent MAY use the Location field for automatic redirection".

This means that if/when the new address at
"https//mirrors.edge.kernel.org"
doesn't have content, the "user agent" (proxy in my case) stops
searching for a copy of the content and returns a 404 (Not Found).

sfo.korg-mirror.kernel.org must return a 302 response when it
refers to mirrors.edge.kernel.org. It can still use 'https', but
unless it is known that mirrors.edge.kernel.org has content, it cannot
use 301.

Use of 301 instead of 302 will terminate the searching for content,
disabling search through the mirror system.

I would prefer that the kernel mirrors NOT stop carrying the suse
content for this problem, as it isn't limited to opensuse, but to
any systems using this as a mirror -- it is a fault of the http->https
system using response code 301 when, as a mirror, it can only use
'302'.