Best practices for client side vs. server side redirects: When to use what ?

Question

I understand that most of the languages support server side redirects (asp.net: Response.Redirect, PHP: header( 'newpage' ) ; ). You could also do a redirect with JavaScript (window.location.href="newLocationURL").

When would you choose one over the other ?

With respect to ASP.net/IIS7(app pool in Integrated mode,enable 32 bit apps=false), I noticed that even when the page has a 302 header, the whole page body is sent to the client side.

And I believe this is not the case with PHP, only headers are sent ? To quote Redirect on client side means following steps:Client-side -> Server-side -> Client-side -> Server-side -> Client-side.

Redirect on Server-Side means:Client-side -> Server-side -> Client-side (headers only)* -> Server-side -> Client-side.

Is there a W3C standard or server side redirect implementation differ from one web server technology to another ?

Edit: I am only concerned about Response.Redirect (in asp.net) and not server.transfer, at least for this discussion

Answer 1

In ASP.Net, there is an important distinction between two kinds of server-side redirects. They are Response.Redirect and Server.Transfer.

If you call Response.Redirect, that entails two round trips to the server. On the first call to the server, the server response directs the browser to request the next page. Requesting that next page constitutes the second round trip to the web server.

If you use Server.Transfer, there is only one round trip. Therefore, there is much less network traffic. However, there is a limitation to using Server.Transfer, which is that the target page has to be on the same web server. That is, you can't Server.Transfer from your web app to www.Google.com. But you can Response.Redirect to it.

There are other details involved with using either of these approaches which you would want to research before using them. However, I believe that it is significant in the context of this question to note that in any language, Response.Redirect may result in much heavier network traffic than is really necessary.

Answer 2

It really depends on where you decide that you need to redirect. If it is server side code that determines that you have to redirect, then it is server side code that issues the redirect command. If you can decide client side that a redirect is needed, then do it from the client code.

It is probably more efficient from client side, since you avoid a the back-and-forth of the server side redirect thing..

Answer 3

The JavaScript example is actually not a redirect. There's no means of a 301/302 response. It is just a simple request which happens during a certain Javascript event long time after the page is arrived. If you do this during page load, then it would have more overhead than a real redirect and it would not work on JS-disabled browsers as well.

Redirects are to be initiated from the server side with a 301/302 response. All webapp languages/frameworks defaults to 302. You can usually make it 301 by adding one extra parameter or code line which instructs that. The benefit of 301 is by the way that the particular request won't be indexed (anymore) by the searchbots.

Answer 4

My experience is that Google Chrome caches 301/302 redirects, and as such does not always actually redirect to the given new URL in Response.Redirect.

I have a situation where an entry form has an OK button for which the Click event is handled server side, to add/update records in a database. As the last step in the OnClick handler, I issue a Response.Redirect to the originating URL (a list of all available records).

Most browsers, like IE and Firefox, will follow the redirect and present the listing page again. But in Google Chrome the page with the entry form is still displayed, so the redirect to the listing page does not happen.

Any ideas how to get around this?