Redirect Considered Harmful

HTTP redirects are the new GoTo.

HTTP redirects are the new symlinks. (WhatIsWrongWithSymlinks?)

HTML coders are the new SoftwareEngineers? Apache is the new Linux?

I don't get it. GoTo is bad because it's used in the context of an otherwise structured system, and it breaks the reader's expectations of that system. I don't see how redirect is comparable.

The existence of redirect does lead to some slight complexity in the interface to the HTTP client library; because the response to the question "What is the content of this page?" might be "MuAnswer! That page is actually somewhere else." (in java, i'd make this an exception, and leave the return value as always being a valid page).

Why couldn't the client library just follow the redirect and return the page at the other end? Then there wouldn't be any additional complexity.

Because then the user of the client library (the client's client, if you will) would have a false assumption about the returned page - that its URL is the URL sent to the client library. This would lead to problems following relative URLs, amongst other things.

If the client library returned a Page object, then the URL could be part of it, and so would be available to the calling code.

True. I still prefer the latter; i suppose it's a matter of taste.

: If you don't like redirects, why like exceptions? Exceptions are also harmful; use them only for exceptional circumstances.

Hmmm... so if I can't do a redirect (cause its bad) how does the browser know where my page moved to?

Redirects are bad because why isn't the resource still there today at the location where it was yesterday?!? Was the original choice of URL so bad that they had to reorganize the entire tree structure?

For my website, it moved because it was originally under a domain I didn't control. It had been there for a few years already, so not wanting to loose any search engine placements (this was back in 1998), I moved my site to a domain I controled, and set up a permanent redirect to the new location.

Then there was the software project (that a friend was writing that I was hosting for him) that eventually grew to a commercial product. When he got his own domain, I then redirected requests to his software package to his new commercial site.

Then there are the few redirects left where I initially made a bad decision in filenames and had to change. It was a bit of a pain in setting up the redirects, but it fixed the filename problem. --SeanConner

Maybe they wanted to refactor. Isn't refactoring supposed to be a good thing?

If your external interface (the tree structure) changes when you refactor, something is wrong.

There are lots of reasons your URL may change. Maybe you want to go to secure sockets, maybe you want add a new server, maybe you want to consolidate two pages, maybe you need to split directories because then have become too big. Tree structures change and if you allow multiple entry points (another structured programming no-no), redirects provide a short-term patch.

Why would you need to change your structure when adding a server? Moving to secure sockets and consolidating two pages aren't refactorings. Splitting a directory seems to the assume the structure of the site has to mirror the local directory structure. Using ApacheHttpd (and other servers, I'm sure) VirtualDirectories? are easily set up.

File renaming is bad because why did you give the file the wrong name in the first place?!?

Beating up on redirects because they shouldn't be necessary in the first place is like, um, like beating up on the workaround instead of the underlying problem.

-- DanielBarlow?, often thought there should be a wiki page discussing the basic pointlessness of iWouldntStartFromHere as a problem solving technique

The landing page to a site often contains logic that determines the client type and redirects to a browser specific URL. Granted, the resulting URL isn't elegant, but it's a necessary evil.

As a protocol, HTTP is stateless and purely REQ/RESP driven. The intent was to inform requesting clients that a resource has moved. Most browsers commonly implement this by just requesting the redirected page on behalf of the user (and good thing too... I sure don't want to click OK on modal message boxes for every redirection!).

Some app servers have implemented request forwarding in their APIs that allow server side logic to pass flow onto another page.

The purists will argue that this violates the intent of HTTP ("I only want the page I'm requesting. Tell me if I need another one") while the pragmatists will argue that page forwarding "cleans-up" the Internet by removing the "chatty" packet bursts associated with REQ-RESP(Redirect pay-load)-REQ Redirect.

--MichaelLeach

If your external interface (the tree structure) changes when you refactor, something is wrong.

You are no more able to make your external interfaces perfect than you are your internal. Refactoring applies to all interfaces.

Doesn't the external behavior of the code change when 'refactoring' the interface? Doesn't that mean it isn't refactoring anymore?

Hmm... Did some of the previous posters forget that "refactoring" can include physically moving a set of pages from one ISP/domain/server-group to another?

"Why did I get the URLs 'wrong' in the first place?" Well, for example:

: Suppose I create a web site using a provider that expects me to use only a certain amount of bandwidth. (Think of some of the free services.) My web site turns out to be popular and generates a LOT of hits. My provider politely tells me to move my site elsewhere; they're also polite enough to temporarily supply a redirect so my visitors can still easily find me.

Strictly speaking, I have refactored, since the URLs have changed (due to a change in who's doing the web hosting). At another level of abstraction, I haven't refactored at all, I've just changed the physical layer. URLs not only reflect logical structure, they also reflect physical structure, and they are influenced by political or business structure ("GeoCities" dictates how its member URLs must be formed, for example).

My point being: no logical-level interface survives its first encounter with the physical implementation.

-- JohnBaldwin

To the refactoring advocates above:

Sure one needs to refactor the internal and external interface. But this happens at two different time and size scales (because changes to the external interface are more expensive the optimum lies at different scales). And in the meantime a migration pattern is needed. For the web this is the redirect. You may propose another one. Some such means is required or else you move away from the optimum efficiency. -- GunnarZarncke

Think outside the box.

An HTTP redirect is an excellent way to respond to a POST request. By having the POST send a redirect, the user can't accidentally repost by clicking the "back" button -- all the pages in their history are the results of GET requests.

It's also a convenient way to handle POST requests when the response is something that needs to be GETtable anyhow -- online shopping carts, and the wiki page you just edited, are two good examples. See RedirectAfterPost.