ZF-3596: Unable to provide HTTP codes as string to Redictor action-helper


In the zf-manual, there is a sample code for Redirector action helper:… Basic Usage Examples

The example code passes the HTTP-code 303 as string , i.e. '303'. But redirector assumes the provided code invalid, and an exception will thrown.

$this->_helper->_redirector->setCode(303) works fine, but $this->_helper->_redirector->setCode("303") failes.

How to solve?

@see: Zend/Controller/Action/Helper/Redirector.php (Line 89) @setHttpResponseCode() @see: Zend/Controller/Response/Abstract.php (Line 242) @ _checkCode()

More info is available on the mailing list:…


Just to comment on this since you emailed the mailinglist about it...

Personally, this is a non-issue for me. HTTP status codes are numbers, not strings. Also, contrary to popular believe there are also types in PHP:

IMHO it's good that the redirector is explicit on this issue and demands a certain type. Casting in the redirector is more expensive cause that would imply casting for everyone who uses the framework, not just for people who tend to be a bit more loose on variables. :) (With no offense meant.)

If you are not sure about what you pass into it, try the following code snippet:

$code = '404';

Marking as a documentation issue, though we may choose to update the code to allow casting strings where ($string == intval($string)).

Scheduling for next minor release (1.6.0GA)

Given that the current code has an is_int() call, casting to int on entry would be more efficient. Also the exception message given when you pass in a string is less than helpful as the code:

$code = '301';

gives the exception message:

Invalid redirect HTTP status code (301) 

Casting to an int solves this far more neatly and is much more programmer friendly to boot.

2 patches attached. 1. zf3596-option1.patch: Simple cast to int (my preference) 2. zf3596-option2.patch: Test for string first (as per Matthew's comment)

Both patches have appropriate unit test.

Personally, I'd like to see patch 1 applied as it's "cleaner" and more efficient in my opinion.

Would someone mind committing it as I don't think I have the karma.

Fixed on trunk in svn r10778 and on release-1.6 in svn r10779.

For posterity, I should probably note that I talked to Matthew Weier O'Phinney on IRC and he agreed with applying the option 1 patch to both trunk and the release-1.6 branch.

Thanks Rob.

Updating for the 1.6.0 release.