HTTP 302: 두 판 사이의 차이

내용 삭제됨 내용 추가됨

인라인

2024년 6월 7일 (금) 23:27 기준 최신판

HTTP 302, 즉 HTTP 응답 상태 코드 302 발견(302 Found)은 URL 리다이렉션을 수행하는 일반적인 방법이다. HTTP/1.0 사양(RFC 1945)은 처음에 이 코드를 정의하고 "발견" 대신 "임시 이동"이라는 설명 문구를 제공했다.

이 상태 코드가 포함된 HTTP 응답은 위치 헤더 필드에 URL을 추가로 제공한다. 이는 위치 필드에 지정된 새 URL에 대해 동일한 두 번째 요청을 생성하도록 사용자 에이전트(예: 웹 브라우저)에 대한 초대이다. 최종 결과는 새 URL로 리다이렉션된다.

많은 웹 브라우저는 이 표준을 위반하는 방식으로 이 코드를 구현했으며, 원래 요청에 사용된 유형(예: POST)에 관계없이 새 요청의 요청 유형을 GET으로 변경했다.^[1] 이러한 이유로 HTTP/1.1(RFC 2616)은 두 동작 사이를 명확하게 하기 위해 새로운 상태 코드 303과 307을 추가했다. 303은 요청 유형을 GET으로 변경하도록 요구하고 307은 원래 전송된 요청 유형을 유지한다. 이러한 명확성으로 인해 더 명확해졌음에도 불구하고 302 코드는 HTTP/1.1 사양을 구현하지 않는 브라우저와의 호환성을 유지하기 위해 여전히 웹 프레임워크에 사용된다.^[2]

결과적으로 RFC 7231(RFC 2616의 업데이트)은 사용자 에이전트가 POST를 GET으로 다시 작성할 수 있도록 정의를 변경한다.^[3]

예시

클라이언트 요청:

GET /index.html HTTP/1.1
Host: www.example.com

서버 응답:

HTTP/1.1 302 Found
Location: http://www.iana.org/domains/example/

같이 보기

각주

↑ Lawrence, Eric. “HTTP Methods and Redirect Status Codes”. 《EricLaw's IEInternals blog》. 2011년 8월 20일에 확인함.
↑ “Request and response objects | Django documentation | Django”. Docs.djangoproject.com. 2014년 6월 23일에 확인함.
↑ “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”. Tools.ietf.org. 2019년 1월 5일에 확인함.

외부 링크

RFC 9110 HTTP Semantics

[1] Lawrence, Eric. “HTTP Methods and Redirect Status Codes”. 《EricLaw's IEInternals blog》. 2011년 8월 20일에 확인함.

[2] “Request and response objects | Django documentation | Django”. Docs.djangoproject.com. 2014년 6월 23일에 확인함.

[3] “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”. Tools.ietf.org. 2019년 1월 5일에 확인함.

[1]

[2]

[3]

@@ 5번째 줄: / 5번째 줄: @@
 이 상태 코드가 포함된 HTTP 응답은 위치 헤더 필드에 URL을 추가로 제공한다. 이는 위치 필드에 지정된 새 URL에 대해 동일한 두 번째 요청을 생성하도록 [[사용자 에이전트]](예: 웹 브라우저)에 대한 초대이다. 최종 결과는 새 URL로 리다이렉션된다.
-많은 웹 브라우저는 이 표준을 위반하는 방식으로 이 코드를 구현했으며, 원래 요청에 사용된 유형(예: [[POST (HTTP)|POST]])에 관계없이 새 요청의 요청 유형을 GET으로 변경했다.<ref>{{cite web |last=Lawrence |first=Eric |url=http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx |work=EricLaw's IEInternals blog |access-date=2011-08-20 |title=HTTP Methods and Redirect Status Codes}}</ref> 이러한 이유로 HTTP/1.1(RFC 2616)은 두 동작 사이를 명확하게 하기 위해 새로운 상태 코드 303과 307을 추가했다. 303은 요청 유형을 GET으로 변경하도록 요구하고 307은 원래 전송된 요청 유형을 유지한다. 이러한 명확성으로 인해 더 명확해졌음에도 불구하고 302 코드는 HTTP/1.1 사양을 구현하지 않는 브라우저와의 호환성을 유지하기 위해 여전히 웹 프레임워크에 사용된다.<ref>{{cite web|url=https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpResponseRedirect |title=Request and response objects &#124; Django documentation &#124; Django |publisher=Docs.djangoproject.com |access-date=2014-06-23}}</ref>
+많은 웹 브라우저는 이 표준을 위반하는 방식으로 이 코드를 구현했으며, 원래 요청에 사용된 유형(예: [[POST (HTTP)|POST]])에 관계없이 새 요청의 요청 유형을 GET으로 변경했다.<ref>{{웹 인용|last=Lawrence |first=Eric |url=http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx |work=EricLaw's IEInternals blog |access-date=2011-08-20 |title=HTTP Methods and Redirect Status Codes}}</ref> 이러한 이유로 HTTP/1.1(RFC 2616)은 두 동작 사이를 명확하게 하기 위해 새로운 상태 코드 303과 307을 추가했다. 303은 요청 유형을 GET으로 변경하도록 요구하고 307은 원래 전송된 요청 유형을 유지한다. 이러한 명확성으로 인해 더 명확해졌음에도 불구하고 302 코드는 HTTP/1.1 사양을 구현하지 않는 브라우저와의 호환성을 유지하기 위해 여전히 웹 프레임워크에 사용된다.<ref>{{웹 인용|url=https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpResponseRedirect |title=Request and response objects &#124; Django documentation &#124; Django |publisher=Docs.djangoproject.com |access-date=2014-06-23}}</ref>
 결과적으로 RFC 7231(RFC 2616의 업데이트)은 사용자 에이전트가 POST를 GET으로 다시 작성할 수 있도록 정의를 변경한다.<ref>{{웹 인용|url=https://tools.ietf.org/html/rfc7231#section-6.4.3 |title=Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content