Re. returning a 500 status on an authentication error, which makes the login screen invisible to MSIE users on windows:
On Tue, May 07, 2002 at 12:41:56PM -0400, SOMEBODY wrote:
I strongly oppose modifying a properly functionng, RFC-conforming product to coddle a non-informative and non-RFC-conforming product. Fix the broken product, not the working one.
(Please note that the quote above was a followup to my message and it was not what I said! ) If I was making a tool/product only for myself, my team or something like that I would fully concur. This is not the case for most zope users. a) If zope is used to support a publically-acessible site it absolutely must work in a manner that makes it convenient and acceptable for MSIE/Windows users: I take it that's not debatable. Since I never user MSIE/Win myself I had a hell of a time figuring out the 500-error bug (blaming it on networking issues and such). This is not a good state of affairs. While i don't like it, MSIE/Win is a de facto standard. (I know this is flame bait... you know what I mean, I feel sick for saying it, so please let's not get into it.) The hard-nosed "don't fix a conforming product line" if taken too strongly it the kind of attitude that could really be bad for zope acceptance. b) It seems that semantically a "server error" (500) code isn't even the right code for this particular problem, so the fix is fine there (although I have not checked the RFC). c) The worse issue is what to do with the other unexpected cases where zope might generate a 500 error as it's a default exception code. On my zope, I want the user to see the message page, if any. Inserting code to detected the browser/system and only change a 500 to a 200 code for MSIE/Win users alone seems fine but I'm not gonna bother doing this myself right now, in particular 'cause I don't know how robust it would be. d) As an aside, does any other browser ever really care about these codes? Greg Dudek http://www.cim.mcgill.ca/~dudek