302 대 303의 예

a 302와 303응답 의 차이점은 무엇입니까 ?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10.3.3 302 발견
10.3.4 303 다른 참조

이것들은 서로 바꿔 쓸 수 있습니까? 아니면 왜 다른 것보다 사용됩니까? 하나를 사용하고 다른 하나는 사용하지 않을 경우의 유스 케이스를 제공해 주시겠습니까?

http redirect

— 다비드 542
소스

답변:

링크 한 페이지의 설명은 의도 된 목적을 상당히 설명하는 것 같습니다.

302 리디렉션은 리디렉션이 일시적 임을 나타냅니다. 클라이언트는 향후 요청에서 원래 URL을 다시 확인해야합니다.

303 리디렉션은 POST요청을 GET리소스 로 리디렉션 하기위한 것입니다 (그렇지 않으면 클라이언트는 새 위치에 대한 요청 방법이 원래 리소스와 동일하다고 가정).

클라이언트를 웹 응용 프로그램의 일부로 리디렉션하지만 항상 웹 응용 프로그램 (예 : URL 단축기)에서 시작할 것으로 예상되는 경우 302 리디렉션이 의미가있는 것 같습니다. 303 리디렉션은 POST클라이언트 (예 : 양식 제출) 로부터 데이터를 수신 할 때 (예 : 표준 페이지 요청) GET대신 검색 할 새 웹 페이지로 리디렉션하려는 경우에 사용 됩니다 POST.

그러나 상태 코드 정의 에서이 메모를 참조하십시오. 대부분의 클라이언트는 302 또는 303에 대해 동일한 작업을 수행합니다.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

— larsks
소스

명확하지만 잘못되었습니다. 303 리디렉션은 영구적 이지 않습니다 . RFC는 "303 응답을 캐시해서는 안됩니다"라고 표시 합니다. 여기에 지정한 설명이 301 리디렉션과 일치합니다.

— Ladadadada

Mea Culpa. 나는 301과 303을 거꾸로했다. 답변을 업데이트했습니다.

— Larsks

현재 308 명이 있습니다

— Miranda

303이 POST를 GET-전체 중지로 리디렉션하는 것이 "의미"하다는 것을 암시하는 것은 약간 오해의 소지가 있다고 생각합니다. 이 사양은 303이 원래 요청 된 방법을 통한 자원 표현의 가용성에 관한 것임을 제안합니다. 예를 들어 인증 된 사용자 만 사용할 수있는 큰 권한으로 보호 된 이미지가있는 경우 303을 사용하여 인증되지 않은 사용자를 더 작은 이미지로 리디렉션 할 수 있습니다. 이러한 경우에 사용 된 요청 방법은 관련이 없습니다.

— 보데의

RFC 는 "이 방법은 주로 POST 활성화 스크립트의 출력이 사용자 에이전트를 선택된 리소스로 리디렉션 할 수 있도록하기 위해 존재합니다."라고 말합니다. "요청에 대한 응답은 다른 URI에서 찾을 수 있으며 해당 자원의 GET 메소드를 사용하여 검색해야합니다." 나는 몇 년 전에 말한 것과 거의 일치한다고 생각하지만 해석의 여지가 있다고 확신합니다.

— larsks

현재 네 가지 다른 리디렉션 유형이 있습니다. 원래 두 개만 있었지만 대부분의 클라이언트가 302 리디렉션을 잘못 구현 했으므로 302를 수신 할 때 가능한 두 가지 동작 간의 차이를 명확히하기 위해 두 개가 추가되었습니다.

연결 한 RFC는 302 리디렉션 섹션에서이를 설명합니다.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

301 리디렉션은 영구 리디렉션입니다. 캐시 가능하며이 URL의 책갈피는 새 URL을 가리 키도록 업데이트해야합니다.
302 리디렉션은 임시 리디렉션입니다. 기본적으로 캐시 할 수 없으며 매번 다시 요청해야합니다 (캐싱 헤더로이를 재정의 할 수 있음). 후속 요청은 원래 요청과 동일한 방법 (POST, GET, CONNECT, PUT, DELETE 등)을 사용해야하며 GET 및 HEAD 요청 이외의 경우 클라이언트는 요청하기 전에 사용자에게 프롬프트를 표시해야합니다. 이것은 클라이언트가 잘못한 부분이며 대부분은 원래 방법에 관계없이 후속 요청에 대한 방법을 GET으로 변경합니다.
후속 요청이 GET 요청으로 명시 적으로 변경되고 확인이 필요하지 않다는 점을 제외하고 303 리디렉션은 302와 동일합니다.
307 리디렉션은 후속 요청이 원래 요청과 명시 적으로 동일하고 GET 및 HEAD 이외의 요청 방법에 대해 사용자로부터 확인을 받아야한다는 점을 제외하고는 302와 동일합니다.

이전 고객은 303 리디렉션을 이해하지 못할 수 있습니다. HTTP / 1.1 요청을하는 모든 것은 303 응답을 이해해야합니다.

300 및 305 응답을 리디렉션으로 간주 할 수 있습니다. 즉, 6 가지 유형이 있습니다.

— 라 다다다
소스

사용 된 리디렉션 유형 (301,302,303 ...)은 검색 엔진이 콘텐츠를 색인화하고 순위를 매기는 방법에 많은 영향을 미칩니다. 일부 스파이더는 일시적으로 리디렉션 된 콘텐츠의 색인 생성을 거부 할 수도 있습니다. 자세한 내용은 다양한 SEO 문헌에서 찾을 수 있습니다 ...

— rackandboneman
소스