While doing QA, I was trying to access a deleted attachment. An error was thrown telling me that the attachment was gone (as expected), but my credentials looked like they were gone (no saved searches in the footer, no login name in the banner either). That's because attachment.cgi first redirected me to the alternate host, then threw the error. We should enforce Bugzilla::Error::_throw_error() to throw errors from the main urlbase, to avoid such confusion.

Ah, well, we can't exactly do that, but we it would probably be better to do some sort of check before the redirect that would avoid this specific case. Otherwise, it seems like you're saying one of two things: (a) Redirect to a special "error page" that we would create just for this purpose (which seems like a lot of complexity to just handle this one small issue). (b) Throw an error about not being able to throw an error (which would be kind of silly).

I mean neither (a) nor (b). Maybe should I simply fix attachment.cgi to first validate the attachment ID and data before redirecting to the alternate host. We will see.

(In reply to comment #2) > Maybe should I simply fix attachment.cgi to first > validate the attachment ID and data before redirecting to the alternate host. Oh cool. That sounds sensible.