Monthly Archives: July 2009

Important to note that Zend Framework _redirect defaults to 302

From the Zend Framework Manual:

_redirect($url, array $options = array()): redirect to another location. This method takes a URL and an optional set of options. By default, it performs an HTTP 302 redirect.

Now you can argue about what the 302 header code SHOULD do. It’s spelled out in W3C:

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

But in the past 302’s have been royally borked by search engines.

For some history, I was peripherally involved in documenting and tracking down the initial cause of these problems when a popular directory app (more or less correctly) used 302 redirects to link to resources. The creator of the program felt that he wasn’t doing anything wrong, but it turned into massive threads in the Search Engine forums.

Due to a glitch, a 302 on these directory sites gave all users of the program the SERPs of sites it linked to. Along with the ire of indignant site owners everywhere. Honest people were called spammers, fights broke out. It was ugly.

It also took a long time for the search engines to fix. Really long. And just when you thought it was safe to go back in the water, it broke again.

Eventually it seems the major problems got fixed for good. There have been countless discussions about this topic. Although I haven’t read the latest, in my opinion, 302s hurt your ranking. Just last week a friend of mine asked me to check out her potential client’s low ranked corporate website (they are a household name), and lo and behold, their homepage has a 302 redirect!

The purpose of this post is mostly to alert Zend Framework developers in case they assumed, as did I, that a redirect would send a 301 header code. Used in the wrong place, the results can be costly!

Therefore, make it a habit to pass in the code you desire each time you use _redirect().

In my opinion, the redirect should either default to 301, or, since the ramifications of an incorrect redirect can be harmful to search engine rankings, a valid code should be required to be passed in. This will engender good habits.

I’d love to hear comments on this issue. In particular, to answer these questions:

  1. What do you think the default in Zend Framework should be and why?
  2. Does W3C’s definition of the 302 work in the real world?
  3. Should W3C’s make any changes to redirect codes and if so, what should they change?
  4. What code should you send to redirect pages in various situations? After logging in… Accessing a page when not logged in (it could be a valid page for a logged in user)… etc..

For those who are curious, the default is set in /path/to/ZendFramework1.84pl1/library/Zend/Controller/Action/Helper/Redirector.php, right after the class statement:
protected $_code = 302;