im sorry i havent read through all the replies, but i have read through several of them. i essentially agree w/ Aschwin here. redirects have been the bane of my existence in several source bases ive worked on. to borrow a phrase (read in closures article mentioned in another thread) they really bump up the 'wtf factor'. and ill tell you whats worse, one of the most horrible things i have ever seen is this crap <meta http-equiv="refresh" content="0;url=http://wikipedia.org"/> which is not too dissimilar. i remember my initial encounter with this construct, it looked as if the page was morphing in front of me, there were no header() directives on the server there were no window.location calls in the javascript, it drove me mad, and then when i discovered what it was i practically became livid. what it boils down to, is the most common usage of header(location:) is a lack of design capabilities by the person writing the code on the server side *ducks*. that said, there are plenty of valid reasons for using them, and i have them in my code in plenty of places, but plain and simple, if you have a decent sized app, handle routing on the server side, period. there is only one caveat i have found that is relevant and that is if GET parameters in a url from a page submission will incite a change to the database schema (which is a bad practice anyway) then what can happen is a page will go to the server, mod the schema, and load up the fresh page (having been internally routed back to the 'view' code lets say). so then you have a problem where the 'layman' user will periodically want to see the latest data on the page (if the data displayed was updated by someone else in the system for example). so then what happens when they refresh the page? (the one w/ the GET params that incite the db schema change) well you get theoretically undefined or at least undesirable behavior,instead of simply refreshing the 'view' logic, a database schema mod is invoked. some situations where i find this mechanism useful, and reasonable are 1. implementing pretty urls 2. preventing access to directories 3. mapping one url or sub-domain to another 4. in pitifully trivial applications (of which i have written a few ;) im sure there are other uses and also im aware that i dont know as much about http as i should or at least thats how i feel about it anyway. im sure there are additional uses when implementing restful apis for example. as aschwin has mentioned about the unnecessary use of server resources (and bandwidth obviously) i cannot agree enough. what i would say to dissuade those who view this as a typical page load is, think about the client experience. 1. unnecessarily long page load time (have to sit through all the mind numbing redirects) 2. additional, unnecessary full-page reloads 3. awkward transitions in the user interface (morphing described earlier from previous experience) this leads to confusion, frustration and in all a degraded experience for the user. not to mention the confusion, frustration and degradation of the programming experience for those who have to cleanup a web of these things on the server side ;) /end rant -nathan
