假设应用程序的 contextPath 为 /ctx，在 http://localhost:8080/ctx/a/b 资源中，我们转发和重定向到 http://localhost:8080/ctx/x/y 资源，分别应该怎么写？

转发，是在同一个应用程序中，请求从由资源 A 处理，到由资源 B 处理。资源 A 和资源 B 属于同一个应用程序的资源，它们总是相对于该应用程序的 contextPath 而言的。转发的资源可以使用相对路径(不以 "/" 开头)和绝对路径(以 "/" 开头，这里的绝对，其实也是相对于某个环境而言的)。转发的资源若使用 "/" 开头，代表的是该资源在该应用程序中是绝对的，注意，是在应用程序的这个前提下是绝对的。
资源 A = http://localhost:8080/ctx/a/b，资源 B = http://localhost:8080/ctx/x/y。在资源 A 中 getRequestDispatcher("/x/y")，由于是以 "/" 开头，因此在应用程序内部是绝对的，即在 http://localhost:8080/ctx 这个环境下，/x/y 代表的是绝对地址。注意，我并没有写 getRequestDispatcher(request.getContextPath() + "/x/y")，这样写的话，同样是在 http://localhost:8080/ctx 这个环境下的绝对地址为 request.getContextPath() + "/x/y"，那么完整的资源是 http://localhost:8080/ctx/ctx/x/y，并不是我们所期望的资源。
在资源 A 中 getRequestDispatcher("x/y") 会如何呢？由于转发的资源不是以 "/" 开头，因此它是一个相对地址，相对于谁呢？相对于做转发操作的资源的地址，即相对于 http://localhost:8080/ctx/a/b，其路径为 http://localhost:8080/ctx/a，因此，转发后的资源的地址为 http://localhost:8080/ctx/a/x/y！如果由资源 /ctx/a/b 转发到 /ctx/a/c，由于这两个资源所处的路径相同，我们当然可以这样写：getRequestDispatcher("c")
综上所述，不建议使用相对路径来转发资源。尽量使用绝对地址来转发资源，同时，不要在资源的前面又画蛇添足的加上 request.getContextPath()，因为转发操作本来就是在同一个应用程序之间来处理的！

重定向，不仅可以重定向到当前应用程序(http://localhost:8080/ctx)中的其它资源，还可以重定向到同一个站点上的其它应用程序(http://localhost:8080/another)中的资源，甚至是使用绝对 URL 重定向到其它站点的资源。
被重定向的资源若是以 "/" 开头，如 /x/y，实际上是相对于主机而言的，即完整的资源路径为 http://localhost:8080/x/y，这并不是我们想要的资源。
被重定向的资源若不是以 "/" 开头，如 x/y，实际上是相对于做重定向操作的资源(http://localhost:8080/ctx/a/b)而言的，即完整的资源路径为 http://localhost:8080/ctx/a/x/y，这也不是我们想要的资源。当然，使用这种方式，我们重定向到 /ctx/a/c，即 sendRedict("c") 当然是没问题的。
使用绝对 URL 还可以将资源重定向到其它站点的资源。
综上所述，做重定向操作时，若想重定向同一个应用程序的其它资源时，同样不推荐使用相对路径，尽量使用绝对路径，同时，务必在资源前面加上 request.getContextPath()。

一句话总结：创建 RequestDispatcher 对象时指定的 URL 以“/”开头，它是相对于当前 WEB 应用程序的根目录；HttpServletResponse.sendRedirect 方法的 URL 以“/”开头，它是相对于整个 WEB 站点的根目录。