Re: [Zope] [ANSWER] 500 error with IE on login
Re. my patch to zope to eliminate the default 500 error code: I considered a patch to the user folder product itself. Although I might have given up too soon, it didn't look feasible based on my limited knowledge of zope internals. I tried the obvious stuff but setting a "local" 302 or other code in the user folder didn't work because it got over-ridden later on the the authentication-catching process. Also, while removing all possibilities for a default 500 error from zope seems bad, note that in all those other (hypothetical) cases MSIE would also prevent you from seeing the potentially informative error page that zope might generate. In short, based on MSIE behaviour I think it's better if zope never generates a 500 error if it might also generate an informative error-message page. I might add this to the collector if I only knew how...
Have you had a look at the user folder you use in order to see where it raises an exception (I guess that, but this might eventually lead to HTTPResponse tacking the error 500 to the response)? Maybe it's possible to patch the user folder(s) to set a 302 header?
On Tue, May 07, 2002 at 12:41:56PM -0400, Gregory Dudek wrote: | Re. my patch to zope to eliminate the default 500 error code: | Also, while removing all | possibilities for a default 500 error from zope seems bad, note that | in all those other (hypothetical) cases MSIE would also prevent you | from seeing the potentially informative error page that zope might | generate. | In short, based on MSIE behaviour I think it's better if zope | never generates a 500 error if it might also generate an informative | error-message page. 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. Here's an example of how broken MSIE is : My school has a section of their web site called Student Information System (SIS). It is where students can register for classes, see their grades and financial information, etc. It is (or was, they may have changed it) open only during certain hours and closed at night. One time my brother (using MSIE) tried to check on classes or something and got the "page can't be displayed" page from MSIE. Having no information from IE to determine what was wrong I then tried myself using galeon (mozilla). It displayed the informative error page the server gave back which explained the hours of operation of the site. The site was working perfectly and giving back useful error messages. IE didn't care, ignored the data from the server, and instead displayed a "you must be an idiot, try again" message. Recently I've even tried turning off that option in IE ("Show friendly HTTP errors" in the Advanced tab), but it didn't pay any attention and continued to give no useful information. Conintue to develop correct software and inform all users that it is MSIE that does not work with the rest of the world and we can build up a critical mass and coerce some sort of corrective action. (which will more likely be a transition to functioning software rather than fixes from MS) -D PS. I don't know which HTTP response code the SIS system returned, and I think it is implemented in PHP. It's just the first detailed example that comes to mind. -- Do not be afraid of those who kill the body but cannot kill the soul. Rather be afraid of the One who can destroy both soul and body in hell. Matthew 10:28 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
On Tue, 7 May 2002, dman wrote:
On Tue, May 07, 2002 at 12:41:56PM -0400, Gregory Dudek 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.
I have to concur completely. If we get in the habit of "fixing" zope all the time to work around IE bugs it will only make it that much harder to make compliant solutions and that much harder to get rid of MS. Fighting a monopoly takes work and I have found it to be worthwhile. What I would propose is that instead we build some kind of browser detection into zope and base the information on what kind of user agent that is acessing zope. That way we could have a work around for IE but we could still move the world towards a more standards compliant solution.
kosh@aesaeion.com wrote:
On Tue, 7 May 2002, dman wrote:
On Tue, May 07, 2002 at 12:41:56PM -0400, Gregory Dudek 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.
I have to concur completely. If we get in the habit of "fixing" zope all the time to work around IE bugs it will only make it that much harder to make compliant solutions and that much harder to get rid of MS. Fighting a monopoly takes work and I have found it to be worthwhile.
What I would propose is that instead we build some kind of browser detection into zope and base the information on what kind of user agent that is acessing zope. That way we could have a work around for IE but we could still move the world towards a more standards compliant solution.
Well, the problem isn't the non-standards compliance of IE. Don't get me started about that. The question is whether sending and "Internal Server Error" status 500 header is the right thing to do, when doing cookie based authentication. While I didn't read up in the http RFC, I doubt that error code 500 is correct. Thinking about it ... since IIRC this RFC isn't talking about something like "cookie-based authentication" (aren't cookies itself not regulated by rfcs?), it seems plausible that they didn't reserve a status code for it. I'm quite sure that while the rfc mandates the client to display the server's error page - instead its own half-assed try of a "friendly" explanation - it OTH doesn't mandate the server to send status code 500 for "Cookie-based authentication required". So we wouldn't work around a bug per se, just as a side effect. Sending an status 500 e.g. might prevent the login page from neing cached - no biggie, but indicates that something is wrong. cheers, oliver
On Wed, May 08, 2002 at 12:43:52AM +0200, Oliver Bleutgen wrote: | kosh@aesaeion.com wrote: | | >On Tue, 7 May 2002, dman wrote: | > | >>On Tue, May 07, 2002 at 12:41:56PM -0400, Gregory Dudek 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. | > | >I have to concur completely. If we get in the habit of "fixing" zope all | >the time to work around IE bugs it will only make it that much harder to | >make compliant solutions and that much harder to get rid of MS. Fighting a | >monopoly takes work and I have found it to be worthwhile. | Well, the problem isn't the non-standards compliance of IE. Don't get me | started about that. Ok. | The question is whether sending and "Internal Server Error" status 500 | header is the right thing to do, when doing cookie based authentication. | While I didn't read up in the http RFC, I doubt that error code 500 is | correct. Ahh, this is totally different than the first impression I got from your message. If zope isn't following the standards right, then by all means fix it :-). Originally I was under the impression of "IE is broken, we should modify zope to help it along". I don't know enough about HTTP to comment further on this. -D -- If anyone would come after me, he must deny himself and take up his cross and follow me. For whoever wants to save his life will lose it, but whoever loses his life for me and for the gospel will save it. What good is it for a man to gain the whole world, yet forfeit his soul? Or what can a man give in exchange for his soul? Mark 8:34-37 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
participants (4)
-
dman -
Gregory Dudek -
kosh＠aesaeion.com -
Oliver Bleutgen