Alex,

Your CGI module is smart enough so that $IN->header() calls are not stacked, but if such a call is made before an $IN->redirect, the redirect never happens.

I had this happen during debugging for the logon-redirect, and it suddenly occured to me that this might be the problem.

It is. There can be no "print" or $IN->header lines before the $IN->redirect.

Bug? Or feature?? <G>


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

That is the way the ordinary CGI.pm works too.

You can't redirect after printing a header as it will just print the redirect to your browser.

It's the same with:

print "Content-type: text/html\n\n";
print "Location: http://www.wiredon.net/\n\n";

...prints:

Location: http://www.wiredon.net

...and doesn't redirect.

The CGI.pm method would print something like:

Status: 302 Moved location: http://www.wiredon.net

Yeah... but Alex's CGI.pm was supposed to be "smarter" <G>

That's why I'm asking.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

>>Your CGI module is smart enough so that $IN->header() calls are not stacked<<

This is standard to CGI.pm too.

Why would you want to print a header anyway if you knew you were redirecting?

Sounds like it may be a logic issue?

Hi,

The way it works is the first call to $IN->header or $IN->redirect returns the headers. Any future calls to header/redirect will return immediately as the headers have already been printed.

It's not an easy change to have it do what you describe, as you must print out the headers before any other text, so if you call print $IN->header, it better actually print them out or you'll be seeing 500 server errors. =)

Cheers,

Alex
--
Gossamer Threads Inc.

Well.... I was just asking :)

It was an obscure thing I was dealing with late at night, where the debug code prevented the real code from working. I hadn't seen it til I was not logged in, and that process had to run. Took awhile to figure out what was going on... all because of a !$DBEUG or print $IN->header() line above the redirect line.

I was getting a blank page, with all my debug warnings, but the redirect wasn't happening.

Is there a way to trap this? Or return an error if $IN->redirect is called after $IN->header() has been called at least once?

In some ways a 500 error is better, as it would have at least helped point to the problem in the error logs.

Maybe, even if the redirect itself is "printed" as text rather than just vaporizing, it would click in a programmer to search for a print $IN->header() line -- I know if that happened that would have been about the first thing on my mind as the cause.

Anyway I needed to ask. The programs are getting more complex, and debug code is more important during development.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.