Headers set to no cache are not honored?

[eluser]drewbee[/eluser]
I am setting them in my extended CI Controller constructor

[eluser]dmorin[/eluser]
alright, using:

Code:

else
    {
        // is_callable() returns TRUE on some versions of PHP 5 for private and protected
        // methods, so we'll use this workaround for consistent behavior
        if ( ! in_array(strtolower($method), array_map('strtolower', get_class_methods($CI))))
        {
            show_404("{$class}/{$method}");
        }
        var_dump($OUT);
        // Call the requested method.
        // Any URI segments present (besides the class/function) will be passed to the method for convenience
        call_user_func_array(array(&$CI, $method), array_slice($URI->rsegments, 2));
        var_dump($OUT);
    }

and setting the same headers you are in the constructor of an extended controller, going to both the default method (none specified in the url) and a non-default method, the headers show up in both var_dump()'s;

So the CI output is working as expected for me. One thing to note which should be an issue is you were using echo print_r() when print_r returns the result to the browser (ie no echo needed). I don't think that would have caused your issue in debugging output but maybe...

[eluser]drewbee[/eluser]
I used var_dump this time around top and bottom as you did above.

On a specified controller/method: correctly outputs above and below output.

On the default controller/method: outputs above but not below. (So same results as the print_r).


Whatever is causing this is definitely in regards to the default controller. The only non-standard part I have set up with that is my default controller name is 'index', and default method is 'index'.

So...

Code:

class Index extends CIEXT_Controller
{
    function __construct() { parent::__construct(); }
    
    function index() { // blah blah }

}

(I'm just quickly typing this out don't mind the syntax)

You know this is going to be because of something so stupid and minute... lol.

Edit: one last thing in your check, make sure you attempt to use the default controller as well. I only seen you testing the default method.

[eluser]dmorin[/eluser]
One very interesing thing that might be happening...I think php5 might call your function index() as a construct in addition to the __construct function (I might be 100% wrong though). If that's the case, I would think only bad things could happen by calling it twice...

To test, maybe put a var_dump('method name'); in both your __construct and your index() function and see how many times each is called? That's about all I can think of trying for now...

[eluser]dmorin[/eluser]
Alright, I reran the test using the default controller and default method, which worked fine. I think did it with my default controller as index and it also worked fine... So it must be something else.

It doesn't make any sense that after calling the controller method, your $OUT is empty. If that were the case, line 254 ($OUT->_display() would fail with a fatal error. Unless you have the display override hook set in which case _display() never gets called so the headers aren't set which would be your entire problem.

[eluser]drewbee[/eluser]
Nope... All is well.

Code:

class Index extends CIEXT_Controller
{
    function __construct() { parent::__construct(); var_dump('constructor'); }
    
    function index() { var_dump('index'); }

}

Output: string(11) "constructor" string(5) "index"

This is just absolutely bewildering. At least it has been narrowed down to the 'default controller/method' for me... gives me some range to shoot at.

I guess I need to go back and take a look at the user_call_func_array method. That is where my disconnect is at without a doubt.

[eluser]dmorin[/eluser]
Hum, not sure where to go from here. Maybe take a few shots in the dark and search your whole project for "$this->output" and "$OUT" and anything else you can think of to see if you can figure out where it's getting unset.

Good luck.

[eluser]drewbee[/eluser]
It's not entering within the IF statement, which means it is evaluating to true. Here is some even stranger food for thought:

I think I have been interpreting this wrong. The variables are not showing up past call_user_func_array because I have a theory that script execution stops at that point. That is why I am getting no output (invalid unitialized variables etc, as well I did a check against $EXT and it doesn't know whether i'm in it or not.

Whatever it is, something in call_user_func_array ends script execution on my default controller. At least this is what it seems.

This is what I don't understand. It is saying nothing more then $CI->method($params[2]+);

[eluser]dmorin[/eluser]
Hum, interesting. Do you have any exit() or die() or anything like that instead of a return statement within the execution path of your default controller/method?

[eluser]drewbee[/eluser]
LOL..................


I have a _show_message() call which is used to remove any templates that may have been added if there are any.

I used echo $this->output->get_output(); and die()....

I did that for some reason to avoid any further processing... but I should be using $output->_display().



::falls on the ground with knife in hand ready to start poking myself::

Thank you very much for your time with this. I knew it was going to be something stupid. It just took a million tries to trace it back to their.