When I pluck a URL from a bug report I expect it to give me a file instead of issuing a "302 Moved" when it wants to point to some newfangled sub-domain instead of the good old way of doing it. I can see valid uses for the new URL scheme but the way the old one now returns an error (and additionally an HTML document) breaks some of my tools. I can only guess I am not the only one experiencing this. $ curl 'https://bugs.gentoo.org/attachment.cgi?id=285623' <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://381929.bugs.gentoo.org/attachment.cgi?id=285623">here</a>.</p> <hr> <address>Apache Server at bugs.gentoo.org Port 443</address> </body></html> I can fix the curl issue by adding the -L option, probably, but it would be better if the HTML document sent along would point out when the URL scheme transition will be complete, since it's now not completely functional and should be at some point (i.e. the original URLs in the bug reports should at some point be replaced with the ultimate ones). wget does not seem to have this problem, as it appears to follow the redirect by default, so I can't say anything about the Severity of this bug.
The 'old' URL sends a Location header along with the HTML page: % curl -v https://bugs.gentoo.org/attachment.cgi\?id\=285623 ... < Location: https://381929.bugs.gentoo.org/attachment.cgi?id=285623 ... <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> ... Location headers are part of the RFC, and if a client doesn't follow them, I guess it's a client issue and not a Bugzilla issue. I think this qualifies as 'invalid'. (fwiw, I'd rather not change the upstream behavior here as well, as it might limit our future options should we ever need to change the URL/attachmentbase again)
