301 영구적으로 이동됨 요청된 리소스가 새 위치로 영구적으로 이동되었으며, 이 리소스에 대한 향후 참조는 이 응답과 함께 반환된 여러 URI 중 하나를 사용해야 합니다. 가능하다면 링크 편집 기능이 있는 클라이언트는 요청된 주소를 서버에서 반환된 주소로 자동 수정해야 합니다. 별도로 지정하지 않는 한 이 응답도 캐시 가능합니다. 응답의 위치 필드에 새 영구 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. GET 또는 HEAD 요청이 아닌 경우 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다. 참고: HTTP/1.0 프로토콜을 사용하는 일부 브라우저의 경우 보내는 POST 요청이 301 응답을 받으면 후속 리디렉션 요청은 GET 메서드가 됩니다.
302 발견 이제 요청된 리소스가 다른 URI의 요청에 일시적으로 응답합니다. 이러한 리디렉션은 일시적이므로 클라이언트는 향후 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache-Control 또는 Expires에 지정된 경우에만 캐시할 수 있습니다. 응답의 위치 필드에 새 임시 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. GET 또는 HEAD 요청이 아닌 경우 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다. 참고: RFC 1945 및 RFC 2068 사양에서는 리디렉션 시 클라이언트가 요청 방법을 변경하는 것을 허용하지 않지만, 기존의 많은 브라우저에서는 302 응답을 303 응답으로 간주하고 위치에 관계없이 GET 메서드를 사용하여 Location에 지정된 URI에 액세스합니다. 원래 요청의 방법입니다. 서버가 클라이언트로부터 기대하는 응답을 명확히 하기 위해 상태 코드 303 및 307이 추가되었습니다.
위키피디아에서 가져온 개념입니다. 읽고 나면 대략적으로 이해할 수 있습니다. 301은 액세스 중인 리소스가 영구적으로 삭제되었으며 클라이언트가 새 URI에 따라 리디렉션되어야 함을 의미하고, 302는 액세스 중인 리소스가 위치의 URI를 사용하여 일시적으로 액세스될 수 있지만 이전 리소스는 여전히 유지됨을 의미합니다. 다음에 다시 방문할 때 리디렉션할 필요가 없을 수도 있습니다.
시나리오 1: 도메인 이름을 변경하고 싶은데 이전 도메인 이름이 더 이상 필요하지 않습니다. 이렇게 하면 사용자가 이전 도메인 이름에 액세스하면 301을 사용하여 새 도메인 이름으로 리디렉션됩니다. 실제로 이는 포함된 도메인 이름에 새 도메인 이름이 포함되어야 함을 검색 엔진에 알려줍니다.
시나리오 2: 로그인 후 지정된 페이지로 리디렉션됩니다. 이 시나리오는 로그인에 성공하고 특정 시스템 페이지로 이동할 때 더 일반적입니다.
시나리오 3 5초 후에 주문 세부정보 페이지로 돌아가는 등 페이지를 자동으로 새로 고쳐야 하는 경우가 있습니다.
시나리오 4 시스템이 업그레이드되거나 특정 기능이 전환될 때 일시적으로 주소를 변경해야 하는 경우가 있습니다.
시나리오 5: Weibo와 같은 짧은 도메인 이름이 사용되며 사용자는 탐색 후 실제 주소로 리디렉션되어야 합니다.
<code class="hljs"><span class="hljs-keyword">public <span class="hljs-function"><span class="hljs-keyword">void <span class="hljs-title">doGet<span class="hljs-params">(HttpServletRequest request, HttpServletResponse response) <span class="hljs-keyword">throws ServletException, IOException { <span class="hljs-comment">//请求重定向的例子 response.setStatus(<span class="hljs-number">301); response.setHeader(<span class="hljs-string">"Location", <span class="hljs-string">"http://127.0.0.1/login.htm"); }</span></span></span></span></span></span></span></span></span></span></code>
사용자가 방문하면 브라우저는 http://127.0.0.1/login.htm으로 리디렉션됩니다
302 리디렉션 및 URL 하이재킹(URL 하이재킹) URL A에서 URL B로 302 리디렉션을 수행할 때 호스트 서버의 암시적 의미는 URL A가 언제든지 마음을 바꾸거나 자체 콘텐츠를 다시 표시하거나 다음으로 리디렉션할 수 있다는 것입니다. 다른 URL 장소. 대부분의 경우 302 리디렉션을 받을 때 대부분의 검색 엔진은 대상 URL인 URL B만 크롤링하면 됩니다. 302 리디렉션이 발생할 때 검색 엔진이 대상 URL B의 100%를 크롤링하면 URL 하이재킹에 대해 걱정할 필요가 없습니다. 문제는 때때로 검색 엔진, 특히 Google이 대상 URL을 항상 크롤링하지 않는다는 것입니다. 예를 들어 URL A는 매우 짧지만 URL B로 302 리디렉션을 수행하고 URL B는 물음표와 같은 일부 매개변수를 포함할 수도 있는 길고 지저분한 URL입니다. 당연히 URL A는 사용자 친화적인 반면, URL B는 보기 흉하고 사용자 친화적이지 않습니다. 현재 Google에서는 여전히 URL A를 표시할 가능성이 높습니다. 검색 엔진 순위 알고리즘은 사람이 아닌 프로그램일 뿐이므로 302 리디렉션이 발생하면 사람처럼 어떤 URL이 더 적합한지 정확하게 판단할 수 없으므로 URL 하이재킹 가능성이 발생합니다. 즉, 부도덕한 사람이 자신의 웹사이트 A에서 귀하의 웹사이트 B로 302 리디렉션을 수행하는 것입니다. 어떤 이유로 Google 검색 결과에는 여전히 웹사이트 A가 표시되지만 사용된 웹페이지의 콘텐츠는 귀하의 웹사이트 B에 있는 콘텐츠입니다. 이러한 상황을 웹사이트 URL 하이재킹이라고 합니다. 당신이 열심히 작성한 내용을 다른 사람이 훔쳐갔습니다. 302 리디렉션으로 인한 URL 하이재킹은 한동안 존재했습니다. 그러나 지금까지 더 나은 해결책은 없는 것 같습니다. 302 리디렉션 문제는 Google Big Daddy 데이터 센터 전환이 진행되는 동안 해결해야 할 대상 중 하나이기도 합니다. 일부 검색 결과를 보면 URL 하이재킹 현상이 개선됐으나 완전히 해결된 것은 아니다.
일반적인 의미는 검색 엔진 순위에 영향을 미치며, 302 리디렉션은 검색 엔진에서 여러 도메인 이름을 사용하여 동일한 웹 사이트를 가리키는 것으로 쉽게 오해할 수 있으며 웹 사이트가 차단된다는 것입니다.
즉, 실제로 302를 사용한 임시 리디렉션이 아닌 이상 다른 경우에는 301을 사용하는 것이 가장 좋습니다
HTTP 상태 코드 https://zh.wikipedia.org/wiki/HTTP 상태 코드
http 상태 코드 301과 302의 자세한 설명과 차이점 - 쓰라린 탐험의 여정 http://blog.csdn.net/grandpang/article/details/47448395
302 리디렉션 http://baike.baidu.com/view/2453504.htm