When one tries to download an attachment, there is a bit too much redirects going on: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=146132 redirects to http://bz-attachments.freebsd.org/attachment.cgi?id=146132 redirects to https://bz-attachments.FreeBSD.org/attachment.cgi?id=146132 We could do without the one in the middle, I think :-)
Adding clusteradm@ and linking a possibly related redirect issue
I'm not sure how to fix this one. There is a parameter attachments_base that controls the parallel domain redirection. The problem is that the bugzilla backend doesn't have the ability to see that a request came in over https. It always does, but attachments.cgi can't "see" the https part. It issues another redirect and loops infinitely. If you are using a browser this isn't normally a big deal because we set strict-transport-security for a long period. A modern browser won't visit http://bz-attachments more than once per year. It'll bypass http:// and go direct to https://. However, fetch(1) doesn't have HSTS persistence and will take the extra detour every time. Having said that, I haven't given up on it yet. I just wanted to let you know I have looked at it and its not a simple fix that's obvious to me. "attachments_base" parameter cannot just be changed.
(In reply to Peter Wemm from comment #2) > "attachments_base" parameter cannot just be changed. attachments_base is set to http://bz-attachments.freebsd.org/ at the moment. Would changing it to https://bz-attachments.freebsd.org/ have any other negative impact? Or should we give it a go?
clusteradm@: Can you comment on comment 3?
Like I said in comment #2 it doesn't work and I don't yet know how to fix it. I have tried it, and can conform that it definitely does not work. It loops infinitely.
This should now be resolved