This presents a longwindeded solution to a problem I posted here. I think I may not be unique in having this problem. Problem: A while back I posted a question here regarding a problem I was having with login screens. Specifically, users using MSIE on Windows were getting a "Server Error" page saying "The page cannot be displayed" (error 500) instead of my login page. The login folder product I was using was the Generic User folder product (GUF) but I am almost certain the problem afflicts other user folder products like Extensible User Folder. I am running zope 2.4 It turns out the problem is unique to MSIE (Internet Explorer) on the windows platform. As far as I know it does not occur with any other browser including mozilla, netscape (even on Windows) or even the Mac version of MSIE (Thanks due to complaw@hal-pc.org from this list in helping run tests). It seems to happen with version 5.5 and version 6.0 of MSIE but not on every machine -- differences might be a subversion/patch issue. Explanation (mainly due to Oliver Bleutgen via this list): the 500 error is generated by zope and appears in the page header. It's part of the mechanism for catching an access violation that leads to a request for login. The problem is that when MSIE sees this error it does not display the rest the login page that follows, but substitutes it's own internally generated page instead. Solutions / Work-around: There are 2 solutions, one based on users changing their preferences the second a code-hack to zope itself. First the easy but sub-optimal work-around: If the user turns off "friendly" error messages in their browser the intercept by internally generated pages can be avoided. Of course, forcing the user to do this is ugly. For a page I made giving detailed user-level instructions, see the following: http://abatonix.dyn.dhs.org/mudcritters/windowsLoginProblem A once-only pointer to this message is generated by the following DTML on my home page ( http://www.mudcritters.com ): <dtml-if "(AUTHENTICATED_USER.getUserName()=='Anonymous User')"> <dtml-if "(_.string.find(REQUEST.get('HTTP_USER_AGENT'),'Windows')>=0) and (_.string.find(REQUEST.get('HTTP_USER_AGENT'),'MSIE')>=0)"> <center> <dtml-if "REQUEST.has_key('MSIEwarning')"> <font color=#FF7f30> <dtml-else> <font size=-1>(Once-only obnoxious mega-sized message.)</font><br> <font size=+5 color="ff0000"> <dtml-call "RESPONSE.setCookie('MSIEwarning', AUTHENTICATED_USER, expires=(ZopeTime() + 365).rfc822(),path='/' )"> </dtml-if> WARNING: As a user of Internet Explorer on Windows, to login properly <a href="windowsLoginProblem"> click here.</font> </a> </center> </dtml-if><dtml-else></dtml-if> Alternate solution: I modified zope not to give a 500 error as a default in such cases. Then things work fine with all browsers and nobody has to muck with any preferences. I actually think the 500 error in inappropriate in this case so I removed it. The code hack may have other side-effects although since most browsers ignore the 500 error I think it should be OK and it runs fine for me. In line 240 of lib/python/HTTPResponse.py (in the zope directory) change the lines: if type(status) is types.StringType: status=lower(status) if status_codes.has_key(status): status=status_codes[status] else: status = 500 self.status=status to read: if type(status) is types.StringType: status=lower(status) if status_codes.has_key(status): status=status_codes[status] else: status = 200 # GD changed above from 500 as a hack self.status=status Sorry this is so long, but I wanted to save the next poor soul who gets bitten by this. Greg Dudek http://www.cim.mcgill.ca/~dudek