[Zope] [ANSWER] 500 error with IE on login

[Oliver Bleutgen]

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