First, ever web page that is sent, static or dynamic, must begin with the HTTP editor, typcially as simple as:

Content-Type: text/html
[download]

(eg, ending with two \n\n); this tells the browser how to 'render' the given page. If you were sending, say, a PDF file, the server should send "Content-Type: application/pdf\n\n", and the browser says "Hey, that's a PDF file, let me launch the PDF plug-in". The HTTP header is a way for content negotiation. But also, if you want to redirect the user without using META commands, you can use the HTTP header line "Redirect: <url>" (I believe that's the format), instead of sending a Content-Type, so that the browser recognizes that you want to send the user elsewhere. If the browser saw the Content-Type line first, it will ignore the Redirect, since it's expecting only data from here out. (The header also contains any other negotiated data that might be sent, such as cookies to be retrieved, or cookies to be sent). Thus, you can only print the HTTP header once, whether it be a Content-Type, a Redirect, or the other limited forms that HTTP standards allow.

CGI.pm of course makes this easy to do since it provides ->header() and ->redirect() functions. But the same logic applies: you can only call any one of these once for a given page; once it's printed, further header functions will have no effect.

So in your case, you only want the header to print if the login is (still) invalid, otherwise you will redirect the user. So the logic that you almost had correct would be to check the login first, then if validated, print the ->redirect(), otherwise, print the ->header() and the login form again. In either case, you only use one header function during the printing of the page, and that will be the first thing printed, triggering the right effects at the end browser.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain