302와 307 리디렉션의 차이점은 무엇입니까?

302와 307 리디렉션의 차이점은 무엇입니까?

---

a 302 FOUND와 307 TEMPORARY REDIRECTHTTP 응답 의 차이점은 무엇입니까 ?

W3 사양 은 임시 리디렉션에 모두 사용되며 응답에서 특별히 허용하지 않는 한 캐시 할 수 없음을 나타냅니다.

---

차이의 리디렉션 문제 POST, PUT그리고 DELETE요청과 어떤 서버의 기대 (사용자 에이전트 행동이다 RFC 2616) :

참고 : RFC 1945 및 RFC 2068은 클라이언트가 경로 재 지정된 요청에 대한 메소드를 변경할 수 없도록 지정합니다. 그러나 대부분의 기존 사용자 에이전트 구현은 원래 요청 방법에 관계없이 Location 필드 값에 대해 GET을 수행하여 302를 303 응답 인 것처럼 처리합니다. 클라이언트에 어떤 종류의 반응이 예상되는지 명확하게 나타내려는 서버에 대해 상태 코드 303 및 307이 추가되었습니다.

또한 30x 리디렉션 코드 에 대한 Wikipedia 기사를 읽으십시오 .

---

307은 사용자 에이전트 가 302 응답을 수신하고 위치 응답 헤더에 GET 요청을 보내는 POST 요청을 취하는 사실상의 행동으로 채택 되었기 때문에 발생했습니다 .

이는 잘못된 동작입니다 . 303 만으로 POST가 GET으로 바뀌어야합니다. 원래 POST 요청이 302를 반환 한 경우 새 URL을 요청할 때 사용자 에이전트는 POST 메소드를 사용하지 않아야합니다.

(307)는 서버가이 방법 변경해야하는 사용자 에이전트을 명확하게 할 수 있도록 도입 하지 위치 응답 헤더를 다음과 같은 경우 클라이언트가 될.

---

307 Internal RedirectGoogle 크롬에서 엄격한 전송 보안이 필요한 것으로 알려진 도메인에 대한 HTTP 호출이 발생하는 경우를 예로들 수 있습니다.

브라우저는 원래 호출과 동일한 방법을 사용하여 원활하게 리디렉션됩니다.

---

302에 대해 예상 : 리디렉션은 NEW_URL에서 동일한 요청 방법 POST를 사용합니다.

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

302, 303에 대한 실제 : NEW_URL에서 POST에서 GET으로 경로 변경 요청 방법 리디렉션

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)

307에 대한 실제 : 리디렉션은 NEW_URL에서 동일한 요청 방법 POST를 사용합니다.

CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL

---

• 301 : 영구 리디렉션 : URL이 오래되어 교체해야합니다. 브라우저는 이것을 캐시합니다.
  사용법 예 : URL이에서 (으)로 이동 /register-form.html했습니다 signup-form.html.
  이 방법은 RFC 7231에 따라 GET으로 변경됩니다. "이력상의 이유로 사용자 에이전트는 후속 요청에 대해 요청 방법을 POST에서 GET으로 변경할 수 있습니다."
• 302 : 임시 리디렉션 HTTP / 1.0 클라이언트에만 사용하십시오. 이 상태 코드는 메소드를 변경해서는 안되지만 브라우저는 어쨌든 변경했습니다. RFC는 다음과 같이 말합니다. "많은 HTTP / 1.1 사전 사용자 에이전트는 이해하지 못합니다 [303]. 이러한 클라이언트와의 상호 운용성이 문제가되는 경우 대부분의 사용자 에이전트가 여기에 설명 된대로 302 응답에 반응하므로 302 상태 코드를 대신 사용할 수 있습니다. "303." 물론 일부 고객은 사양에 따라 구현할 수 있으므로 이러한 고대 고객과의 상호 운용성이 중요하지 않은 경우 일관된 결과에 303이 더 좋습니다.
• 303 : 임시 리디렉션, 메소드를 GET으로 변경
  사용법 예 : 브라우저가에 POST를 보낸 경우 /register.php이제로드 (GET) /success.html합니다.
• 307 : 요청을 동일하게 반복하는 임시 리디렉션.
  사용법 예 : 브라우저가에 POST를 보낸 경우에서 POST /register.php를 다시 실행하도록 지시합니다 /signup.php.
• 308 : 영구 리디렉션, 요청을 동일하게 반복합니다. 307이 303의 "방법 변경 없음"대응 인 경우,이 308 상태는 301의 "방법 변경 없음"대응됩니다.

RFC 7231 (2014 년부터) 은 읽기 쉽고 지나치게 장황하지 않습니다. 정확한 답을 알고 싶다면 권장되는 내용입니다. 다른 답변은 1999 년부터 RFC 2616을 사용하지만 아무것도 변경되지 않았습니다.

RFC 7238 은 308 상태를 지정합니다. 실험적인 것으로 간주되지만 2016 년 모든 주요 브라우저 에서 이미 지원되었습니다 .

---

Also, for server admins, it may be important to note that browsers may present a prompt to the user if you use 307 redirect.

For example*, Firefox and Opera would ask the user for permission to redirect, whereas Chrome, IE and Safari would do the redirect transparently.

_{*per Bulletproof SSL and TLS (page 192).}

---

In some use cases, 307 redirects might be abused by an attacker to learn the victim's credentials.

Further information can be found in section 3.1 of A Comprehensive Formal Security Analysis of OAuth 2.0.

The authors of the above paper suggest the following:

Fix. Contrary to the current wording in the OAuth standard, the exact method of the redirect is not an implementation detail but essential for the security of OAuth. In the HTTP standard (RFC 7231), only the 303 redirect is defined unambigiously to drop the body of an HTTP POST request. All other HTTP redirection status codes, including the most commonly used 302, leave the browser the option to preserve the POST request and the form data. In practice, browsers typically rewrite to a GET request, thereby dropping the form data, except for 307 redirects. Therefore, the OAuth standard should require 303 redirects for the steps mentioned above in order to fix this problem.

참고URL : https://stackoverflow.com/questions/2068418/whats-the-difference-between-a-302-and-a-307-redirect