RequestDispatcher.forward () 대 HttpServletResponse.sendRedirect ()

forward()과 의 개념적 차이점은 무엇입니까 sendRedirect()?

requestDispatcher-forward () 메서드

1. 이 forward방법 을 사용할 때 요청은 추가 처리를 위해 동일한 서버 내의 다른 리소스로 전송됩니다.

2. 의 경우 forward웹 컨테이너가 모든 처리를 내부적으로 처리하고 클라이언트 또는 브라우저가 관련되지 않습니다.

3. 시 forward온이라고 requestDispatcher객체 우리의 오랜 요청 객체가 우리의 요청을 처리하는 것입니다 새 자원에 존재하므로, 우리는 요청과 응답 객체를 전달합니다.

4. 시각적으로 전달 된 주소를 볼 수 없으며 투명합니다.

5. 이 forward()방법을 사용하는 것이 sendRedirect.

6. forward를 사용하여 리디렉션하고 새 리소스에서 동일한 데이터를 사용하려는 request.setAttribute()경우 요청 객체를 사용할 수 있으므로 사용할 수 있습니다.

SendRedirect

1. 의 경우 sendRedirect요청은 추가 처리를 위해 다른 리소스, 다른 도메인 또는 다른 서버로 전송됩니다.

2. 를 사용 sendRedirect하면 컨테이너가 요청을 클라이언트 또는 브라우저로 전송하므로 sendRedirect메서드 내부에 제공된 URL 이 클라이언트에 대한 새 요청으로 표시됩니다.

3. sendRedirect호출의 경우 이전 요청 및 응답 개체는 브라우저에서 새 요청으로 처리되므로 손실됩니다.

4. 주소 표시 줄에서 새로 리디렉션 된 주소를 볼 수 있습니다. 투명하지 않습니다.

5. sendRedirect완전히 새로운 요청이 생성되고 이전 요청 객체가 손실되기 때문에 한 번의 추가 왕복이 필요하기 때문에 더 느립니다. 두 개의 브라우저 요청이 필요합니다.

6. 그러나에서 sendRedirect새 리소스에 동일한 데이터를 사용하려면 세션에 데이터를 저장하거나 URL과 함께 전달해야합니다.

어느 것이 좋습니까?

방법이 더 유용한 시나리오에 따라 다릅니다.

제어가 새로운 서버 또는 컨텍스트로 전송되고 완전히 새로운 작업으로 처리되기를 원하면 sendRedirect. 일반적으로 웹 페이지를 브라우저를 다시로드 할 때 작업을 안전하게 반복 할 수 있고 결과에 영향을주지 않는 경우 포워드를 사용해야합니다.

출처

웹 개발 세계에서 "리디렉션"이라는 용어 Location는 클라이언트가 새로운 GET 요청을 보내야하는 새 URL이 포함 된 헤더 만있는 빈 HTTP 응답을 클라이언트에 보내는 행위입니다 . 그래서 기본적으로:

• 클라이언트는에 HTTP 요청을 보냅니다 some.jsp.
• 서버는 Location: other.jsp헤더 와 함께 HTTP 응답을 다시 보냅니다.
• 클라이언트가에 HTTP 요청을 보냅니다 other.jsp(이는 브라우저 주소 표시 줄에 반영됩니다!).
• 서버는 HTTP 응답을 other.jsp.

웹 브라우저의 내장 / addon 개발자 도구 세트로 추적 할 수 있습니다. Chrome / IE9 / Firebug에서 F12를 누르고 '네트워크'섹션을 확인하여 확인하세요.

정확히 위의 내용은 sendRedirect("other.jsp"). 는 RequestDispatcher#forward()리디렉션을 보내지 않습니다. 대신 대상 페이지의 콘텐츠를 HTTP 응답으로 사용합니다.

• 클라이언트는에 HTTP 요청을 보냅니다 some.jsp.
• 서버는 HTTP 응답을 other.jsp.

그러나 원래 HTTP 요청이 some.jsp였으므로 브라우저 주소 표시 줄의 URL은 변경되지 않습니다. 또한 뒤에있는 컨트롤러에 설정된 모든 요청 속성 some.jsp은에서 사용할 수 있습니다 other.jsp. 기본적으로 클라이언트가에서 새 HTTP 요청 을 생성하도록 강요 하여 모든 속성 other.jsp을 some.jsp포함 하는 원래 요청을 버리기 때문에 리디렉션 중에 발생하지 않습니다 .

이는 RequestDispatcherMVC 패러다임 및 / 또는 직접 액세스로부터 JSP를 숨기고 싶을 때 매우 유용합니다. JSP를 /WEB-INF폴더 에 넣고 Servlet요청을 제어, 전처리 및 후 처리하는를 사용할 수 있습니다 . /WEB-INF폴더 의 JSP는 URL로 직접 액세스 할 수 없지만 Servlet은를 사용하여 액세스 할 수 있습니다 RequestDispatcher#forward().

당신은 예를 들어 JSP의에서 파일 수 /WEB-INF/login.jsp와 LoginServlet온 매핑 된 url-pattern의를 /login. 를 호출 http://example.com/context/login하면 서블릿 doGet()이 호출됩니다. 당신은 할 수있는 사전 거기 처리 물건과 마지막으로 앞으로 요청 등이 :

request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);

양식을 제출할 때 일반적으로 다음을 사용합니다 POST.

<form action="login" method="post">

이렇게하면 서블릿 doPost()이 호출되고 거기에서 사후 처리 작업을 수행 할 수 있습니다 (예 : 유효성 검사, 비즈니스 논리, 사용자 로그인 등).

오류가있는 경우 일반적으로 요청을 동일한 페이지로 다시 전달 하고 입력 필드 옆에 오류를 표시하는 식으로 진행합니다. RequestDispatcher이것을 위해 사용할 수 있습니다 .

A는 경우 POST에 성공, 당신은 일반적으로 할 리디렉션 요청이 사용자가 새로 고침 요청 (예 : F5를 누르거나 역사를 다시 탐색) 때 다시 제출 수 없기 때문 요청을.

User user = userDAO.find(username, password);
if (user != null) {
    request.getSession().setAttribute("user", user); // Login user.
    response.sendRedirect("home"); // Redirects to http://example.com/context/home after succesful login.
} else {
    request.setAttribute("error", "Unknown login, please try again."); // Set error.
    request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to same page so that you can display error.
}

따라서 리디렉션 은 클라이언트에게 GET주어진 URL에서 새 요청을 시작 하도록 지시합니다 . 요청을 새로 고치면 초기 요청이 아닌 리디렉션 된 요청 만 새로 고쳐집니다. 이렇게하면 "이중 제출"과 혼동 및 나쁜 사용자 경험을 방지 할 수 있습니다. 이를 POST-Redirect-GET패턴 이라고도합니다 .

또한보십시오:

• 서블릿은 어떻게 작동합니까? 인스턴스화, 세션, 공유 변수 및 멀티 스레딩
• 서블릿의 doGet 및 doPost
• JSP에서 유효성 검사를 수행하고 오류 메시지를 동일한 형식으로 표시하는 방법은 무엇입니까?
• HttpServletResponse sendRedirect 영구

RequestDispatcher인터페이스를 사용하면 앞으로 서버 측을 수행 할 수 있습니다 / 반면에 포함 sendRedirect()클라이언트 측 리디렉션을 수행합니다. 클라이언트 측 리디렉션에서 서버는 302(임시 리디렉션) 의 HTTP 상태 코드를 다시 전송 하여 웹 브라우저가 GET리디렉션 된 위치에서 콘텐츠에 대한 새로운 HTTP 요청 을 발행하게합니다 . 반대로 RequestDispatcher인터페이스를 사용할 때 새 리소스에 대한 포함 / 전달은 전적으로 서버 측에서 처리됩니다.

forward () 메서드와 sendRedirect () 메서드의 주요 차이점은 forward ()의 경우 리디렉션이 서버 끝에서 발생하고 클라이언트에 표시되지 않지만 sendRedirect ()의 경우 리디렉션이 클라이언트 끝에서 발생하고 표시된다는 것입니다. 클라이언트에게.

이러한 방법 중 하나는 수행하려는 작업에 따라 "더 나은", 즉 더 적합 할 수 있습니다.

서버 측 리디렉션은 브라우저를 왕복하지 않고 다른 페이지에서 데이터를 가져 오는 한 더 빠릅니다. 그러나 브라우저에 표시되는 URL은 여전히 ​​원래 주소이므로 약간의 불일치가 발생합니다.

클라이언트 측 리디렉션은 완전히 다른 서버로 보내거나 프로토콜을 변경 (예 : HTTP에서 HTTPS로)하거나 둘 다 할 수있는 한 더 다양합니다. 그리고 브라우저는 새 URL을 인식합니다. 그러나 서버와 클라이언트 사이에 추가로 앞뒤가 필요합니다.

SendRedirect()서버 간의 콘텐츠를 검색합니다. 콘텐츠의 URL을 전송하여 브라우저를 친밀 화해야하기 때문에 속도가 느립니다. 그런 다음 브라우저는 동일한 서버 또는 다른 서버 내에서 콘텐츠에 대한 새 요청을 생성합니다.

RquestDispatcher내가 생각하는 서버 내에서 콘텐츠를 검색하는 것입니다. 서버 측 프로세스이며 SendRedirect()방법에 비해 더 빠릅니다 . 그러나 문제는 필요한 날짜 또는 콘텐츠를 검색하는 서버의 브라우저를 은밀하지 않으며 URL 탭에서 URL을 변경하도록 브라우저에 요청하지 않을 것입니다. 사용자에게 불편 함이 거의 없습니다.

제어권을 다른 도메인으로 이전해야하거나 작업을 분리해야하는 경우 기술적으로 리디렉션을 사용해야합니다.

예를 들어 결제 애플리케이션에서 먼저 PaymentProcess를 수행 한 다음 displayPaymentInfo로 리디렉션합니다. 클라이언트가 브라우저를 새로 고치면 displayPaymentInfo 만 다시 수행되고 PaymentProcess가 반복되지 않습니다. 그러나이 시나리오에서 forward를 사용하면 PaymentProcess와 displayPaymentInfo가 모두 순차적으로 다시 실행되어 데이터가 일치하지 않을 수 있습니다.

다른 시나리오의 경우 sendRedirect보다 빠르기 때문에 forward가 사용하기에 효율적입니다.

요청 디스패처는 웹 리소스에서 다른 웹 리소스로 요청 또는 응답을 디스패치하는 데 사용되는 인터페이스입니다. 주로 두 가지 방법이 있습니다.

1. request.forward(req,res):이 방법은 한 웹 리소스에서 다른 리소스로 요청을 전달하는 데 사용됩니다. 즉, 한 서블릿에서 다른 서블릿으로 또는 한 웹 애플리케이션에서 다른 웹 애플리케이션으로.

2. response.include(req,res):이 방법은 한 서블릿의 다른 서블릿에 대한 응답을 포함하는 데 사용됩니다.

참고 : 요청 디스패처를 사용하여 동일한 서버에서 요청 또는 응답을 전달하거나 포함 할 수 있습니다.

request.sendRedirect():이를 사용하여 요청 또는 응답을 다른 서버에 전달하거나 포함 할 수 있습니다. 여기서 클라이언트는 페이지를 리디렉션하는 동안 알림을 받지만 위의 프로세스에서 클라이언트는 알림을받지 못합니다.

간단하게 차이 사이 Forward(ServletRequest request, ServletResponse response)와sendRedirect(String url) 있다

앞으로():

1. 그만큼 forward() 메서드는 서버 측에서 실행됩니다.
2. 요청은 동일한 서버 내의 다른 리소스로 전송됩니다.
3. 클라이언트의 요청 프로토콜에 의존하지 않습니다. forward ()메소드는 서블릿 컨테이너에서 제공 .
4. 요청은 대상 리소스에서 공유됩니다.
5. 이 메서드에서는 호출이 하나만 사용됩니다.
6. 서버 내에서 사용할 수 있습니다.
7. 전달 된 메시지를 볼 수 없으며 투명합니다.
8. 이 forward()방법은 방법보다 빠릅니다 sendRedirect().
9. RequestDispatcher인터페이스 에서 선언됩니다 .

sendRedirect () :

1. sendRedirect () 메서드는 클라이언트 측에서 실행됩니다.
2. 요청은 다른 리소스로 다른 서버로 전송됩니다.
3. sendRedirect () 메서드는 HTTP에서 제공되므로 HTTP 클라이언트에서만 사용할 수 있습니다.
4. 대상 리소스에 대한 새 요청이 생성됩니다.
5. 두 개의 요청 및 응답 호출이 사용됩니다.
6. 서버 내부 및 외부에서 사용할 수 있습니다.
7. 리디렉션 된 주소를 볼 수 있지만 투명하지 않습니다.
8. sendRedirect () 메서드는 새 요청이 생성 될 때 이전 요청 객체가 손실되기 때문에 느립니다.
9. HttpServletResponse에서 선언됩니다.