Sigstore and SBOM documentation under /download/* broken

[sethmlarson]

I believe these CMS pages (/download/sbom and /download/sigstore) were made unavailable by the added redirect rules.

[ewdurbin]

Can the pages be moved under /downloads/? It seems for whatever reason that was the "chosen" name at some point in favor of /download/

[hugovk]

https://www.python.org/download/sbom/ and https://www.python.org/download/sigstore/ are currently working.

Do they still need moving under /downloads/ or can this issue be closed?

[JacobCoffee]

@ewdurbin Do we need to add specific redirects for these like

location ~ ^/download/sbom/$ {
	return 301 https://www.python.org/downloads/sbom/;
}

location ~ ^/download/sigstore/$ {
	return 301 https://www.python.org/downloads/sigstore/;
}

I tried changing the page path in admin but then the old URL 404'd (expected) but the new one 500'd... i was figuring it was due to NGINX mess

[ewdurbin]

@sethmlarson do you have a preference on the way this is resolved?

[sethmlarson]

@ewdurbin I think in a perfect world we end up with everything under /downloads/ and redirect the old URLs to the new? I don't know how the CMS interacts with the pythondotorg backend, though, does one take precedence over the other?

[ewdurbin]

I don't think specific nginx redirects are necessary since they can be added in the redirects app. But I was able to reproduce the 500 locally by temporarily setting DEBUG=False in pydotorg/settings/local.py.

Seems it has something to do with the url_name context processor and a conflict when resolving the page urls.

/downloads/sbom and /downloads/sigstore conflict with the download_os_list url config and instigates this bug.

One expedient option would be to rename the pages as /downloads/metadata/sbom and /downloads/metadata/sigstore. Are those acceptable @sethmlarson ?

[sethmlarson]

@ewdurbin Those routes work for me! Thanks :)

[ewdurbin]

All set!