From da78a9e329e272dedb2400b79a3bdeebff387d47 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:17 -0500 Subject: initial commit --- files/ko/web/http/redirections/index.html | 256 ++++++++++++++++++++++++++++++ 1 file changed, 256 insertions(+) create mode 100644 files/ko/web/http/redirections/index.html (limited to 'files/ko/web/http/redirections') diff --git a/files/ko/web/http/redirections/index.html b/files/ko/web/http/redirections/index.html new file mode 100644 index 0000000000..86d37e976a --- /dev/null +++ b/files/ko/web/http/redirections/index.html @@ -0,0 +1,256 @@ +--- +title: Redirections in HTTP +slug: Web/HTTP/Redirections +translation_of: Web/HTTP/Redirections +--- +
{{HTTPSidebar}}
+ +

URL 리다이렉션 혹은 URL 포워딩은 페이지 따위의 실제 리소스, 폼 혹은 전체 웹 애플리케이션이 다른 URL에 위치하고 있는 상태에서 링크를 존속시키는 기술입니다. HTTP는 많은 목표를 위해 사용되는 이런 동작을 수행하기 위해 특별한 종류의 응답인 HTTP 리다이렉트를 제공합니다: 사이트 유지관리가 진행 중인 상태에서의 일시적인 리다이렉션, 사이트 아키텍쳐의 변경 이후에도 외부 링크를 동작하는 상태로 유지시키기 위한 영구적인 리다이렉션, 파일 업로드 시 진행 상태 페이지 그리고 그 외의 수많은 리다이렉션들 ...

+ +

원칙

+ +

HTTP에서, 리다이렉션은 요청에 대해 특별한 응답(리다이렉트)을 전송함으로써 촉발됩니다. HTTP 리다이렉트는 3xx 상태 코드를 지닌 응답입니다. 리다이렉트 응답을 수신한 브라우저는, 제공된 새로운 URL을 사용하며 그것을 즉시 로드합니다: 대부분의 경우, 리다이렉션은 사용자에게는 보이지 않는데다가, 적은 성능 저하를 일으킵니다.

+ +

+ +

리다이렉트에는 몇 가지 유형이 있으며 세 가지 카테고리로 나누어집니다: 영속적, 일시적 그리고 특수 리다이렉션.

+ +

영속적인 리다이렉션

+ +

이 리다이렉션은 영원히 지속됨을 의미합니다. 원래의 URL이 더 이상 사용되지 않아야 하며 새로운 URL을 더 선호해야 함을 시사합니다. 검색 엔진 로봇은 그들의 인덱스 내에서 리소스에 대한 연관 URL의 갱신을 촉발시킵니다.

+ + + + + + + + + + + + + + + + + + + + + + + + +
코드텍스트메서드 핸들링일반적인 유스케이스
301Moved Permanently{{HTTPMethod("GET")}} 메서드는 변경되지 않습니다.
+ 다른 메서드들은  {{HTTPMethod("GET")}}로 변하거나 변하지 않을수도 있습니다.[1]		웹 사이트의 재편성.
308Permanent Redirect메서드와 본문은 변하지 않습니다.GET이 아닌 링크/동작을 지닌, 웹 사이트의 재편성.
+ +

[1] 명세는 메서드 변경을 허용할 의도가 없으나, 사실 상 사용자 에이전트들이 그렇게 하고 있습니다. 308 은 GET이 아닌 메서드를 사용할 때 동작의 애매모호함을 제거하고자 만들어졌습니다.

+ +

일시적인 리다이렉션

+ +

때때로 요청된 리소스는 그것의 표준 위치에서 접근할 수 없고 다른 위치에서 접근 가능한 경우가 있습니다. 이런 경우 일시적인 리다이렉트가 사용될 수 있습니다. 검색 엔진 로봇은 새로운, 일시적인 링크를 기억하지 못합니다. 일시적인 리다이렉션은 일시적인 진행율 페이지를 표시하고자 리소스를 만들고 갱신하며 삭제할 때 사용될 수 도 있습니다.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
코드텍스트메서드 핸들링일반적인 유스 케이스
302Found{{HTTPMethod("GET")}} 메서드는 변경되지 않습니다.
+ 다른 메서드들은  {{HTTPMethod("GET")}}로 변하거나 변하지 않을수도 있습니다.[2]		웹 페이지가 예측하지 못한 이유로 일시적으로 이용 불가능할 때 가 있습니다. 그런 이유로, 검색 엔진은 그들의 링크를 갱신하지 않습니다.
303See Other{{HTTPMethod("GET")}} 메서드는 변경되지 않습니다.
+ 다른 메서들은 GET 메서드로 변경됩니다(본문을 잃게 됩니다).		동작을 다시 촉발시키는 페이지 리프레시를 막기 위해 {{HTTPMethod("PUT")}} 혹은  {{HTTPMethod("POST")}} 뒤에 사용됩니다.
307Temporary Redirect메서드와 본문은 변경되지 않습니다.웹 페이지가 예측하지 못한 이유로 일시적으로 이용 불가능할 때 가 있습니다. 그런 이유로, 검색 엔진은 그들의 링크를 갱신하지 않습니다. GET이 아닌 링크/동작이 사이트에서 이용 가능할 때 302보다 더 좋습니다.
+ +

[2] 명세에는 메서드 변경을 허용할 의도가 없으나, 실질적으로 사용자 에이전트들이 그렇게 하고 있습니다. 307 은 GET이 아닌 메서드들을 사용하는 경우 동작의 애매모호함을 제거하기 위해 만들어집니다.

+ +

특수 리다이렉션

+ +

이런 보통 리다이렉션과 더불어, 특별한 두 가지 리다이렉션이 더 있습니다. {{HTTPStatus("304")}} (수정되지 않음)은 (오랜된)로컬에 캐시된 복사본으로 페이지를 리다이렉트시키며, {{HTTPStatus("300")}} (다중 선택)은 수동 리다이렉션입니다:브라우저에 의해 웹 페이지로 표현되는 분문은 가능한 리다이렉션을 나열하며 사용자는 그 중 하나를 선택하기 위해 클릭합니다.

+ + + + + + + + + + + + + + + + + + + + + +
코드텍스트일반적인 유스케이스
300Multiple Choice이런 경우가 많지는 않습니다: 본문의 HTML 페이지 내에 선택지가 나열됩니다. {{HTTPStatus("200")}} OK 상태와 함께 서브될 수 있습니다.
304Not Modified캐시 리프레시: 캐시 값이 여전히 사용 가능할 정도로 신선함을 가리킵니다.
+ +

리다이렉션을 명시하는 대체 방법

+ +

HTTP 리다이렉트가 리다이렉션을 정의하는 유일한 방법은 아닙니다. 두 개의 다른 방법이 존재합니다: {{HTMLElement("meta")}} 엘리먼트를 사용하는 HTML 리다이렉션과 DOM을 사용하는 자바스크립트 리다이렉션이 있습니다.

+ +

HTML 리다이렉션

+ +

HTTP 리다이렉트는 리다이렉션을 만드는 가장 좋은 방법이지만, 때때로 웹 개발자는 서버에 대한 제어권을 가지고 있지 않거나 그것을 구성할 수 없는 경우가 있습니다. 이런 특수한 상황들 때문에, 웹 개발자들은 refresh를 설정하기 위해 페이지의 {{HTMLElement("head")}} 내에 {{HTMLElement("meta")}} 엘리먼트와 {{htmlattrxref("http-equiv", "meta")}} 속성으로 HTML 페이지를 만들 수 있습니다. 해당 페이지를 디스플레이할 때, 브라우저는 이 엘리먼트를 발견하고 표시된 페이지로 이동할 것입니다.

+ +
<head>
+  <meta http-equiv="refresh" content="0;URL='http://www.example.com/'" />
+</head>
+
+ +

{{htmlattrxref("content")}} 속성은 주어진 URL로 리다이렉트 하기 이전에 브라우저가 얼마만큼의 시간(초)을 기다려야 하는지를 나타내는 숫자로 시작됩니다. 더 나은 접근성을 위해 항상 0으로 설정하시기 바랍니다.

+ +

두 말할 필요없이, 이 메서드는 HTML 페이지(혹은 그와 유사한 무언가)에서만 동작하며 이미지나 다른 어떤 종류의 컨텐츠에 대해서 사용될 수 없습니다.

+ +
+

이런 리다이렉션들이 브라우저에서 뒤로 가기 버튼을 무용지물로 만든다는 것을 기억하시기 바랍니다: 해당 헤더가 있는 페이지로 다시 돌아갈 수 있는지만 즉시 앞으로 이동하게 될겁니다.

+
+ +

자바스크립트 리다이렉션

+ +

자바스크립트 내에서의 리다이렉션은 {{domxref("window.location")}} 프로퍼티에 값을 설정해서 만들어지며 새로운 페이지가 로드됩니다.

+ +
window.location = "http://www.example.com/";
+ +

HTML 리다이렉션처럼, 모든 리소스에서 동작하는 것은 아니며, 명백하게 자바스크립트를 실행한 클라이언트 상에서만 동작합니다. 하지만 다른점은, 예를 들어 어떤 조건이 충족되는 경우에만 리다이렉션을 촉발시킬 수 있다는 점에서 더 많은 가능성을 가지고 있습니다.

+ +

우선 순위

+ +

URL 리다이렉션에 대한 세 가지 가능성이 있기에, 몇 가지 방법이 동시에 지정될 수 있는데, 어떤 것이 먼저 적용될까요? 우선 순위는 다음과 같습니다:

+ +
    +
  1. 페이지가 읽힌 적도 없고 전송된 적도 없는 경우, HTTP 리다이렉트가 항상 먼저 실행됩니다.
    2. +
  2. 어떤 HTTP 리다이렉트로 없는 경우에, HTML 리다이렉트 ({{HTMLElement("meta")}})가 실행됩니다.
    3. +
  3. 자바스크립트 리다이렉트는 최후의 순단으로써 사용되며, 클라이언트 측에서 자바스크립트를 활성화시킨 경우에만 사용할 수 있습니다.
    4. +
+ +

가능한 경우, 항상 HTTP 리다이렉트를 사용해야 하며, {{HTMLElement("meta")}} 엘리먼트를 사용해서는 안됩니다. 만약 개발자가 HTTP 리다이렉트를 변경하고 HTML 리다이렉트를 잊는다면, 리다이렉트는 더 이상 동일한 한 것이 아니거나, 무한 루프로 종료되거나 다른 악몽이 시작될 수도 있습니다.

+ +

유스 케이스

+ +

리다이렉트에 대한 많은 유스 케이스들이 존재하지만, 모든 리다이렉트들이 성능과 직결되므로, 리다이렉트의 사용은 최소한으로 유지되어야 합니다.

+ +

도메인 앨리어싱

+ +

이상적으로, 하나의 로케이션이 존재하고, 그래서 하나의 리소스에 대해 하나의 URL이 존재한다고 가정하겠습니다. 그러나 하나의 리소스에 대한 대체 이름을 갖고자 할 때가 있을 수 있습니다 (www 접두사를 갖거나 갖지 않는 몇몇 도메인 혹은 URL을 더 짧고 기억하기 쉽도록하는 등...). 이런 경우, 리소스를 복제하기 보다는 실제 (정식) URL에 대한 리다이렉트를 사용하는 것이 더 유용합니다.

+ +

도메인 앨리어싱을 하는 경우는 다음과 같습니다.

+ + + +

링크 유지하기

+ +

웹 사이트를 다시 만들때, 리소스의 URL이 변경되기 마련입니다. 새로운 네이밍 계획과 일치하도록 웹 사이트의 내부 링크를 갱신할 수 있는 경우조차도, 외부 리소스에 의해 사용되는 URL에 대해서는 어쩔 수가 없습니다. 그들은 당신에게 소중한 사용자이므로(또 SEO에 도움이 되길 바라는 마음으로) 해당 링크를 깨뜨리고 싶지 않을 것이기에, 이전 URL에서 새로운 URL로의 리다이렉트를 설정하려 할 겁니다.

+ +
+

이 기술 또한 내부 링크에 대해서 동작하므로, 내부 리다이렉트는 피해야 할 겁니다. 리다이렉트는 상당한 성능 비용이 드므로(추가적인 HTTP 요청이 수행되므로) 내부 링크를 바로잡아 내부 다이렉트를 피할 수 있다면 해당 링크를 수정해야 합니다.

+
+ +

안전하지 않은 요청에 대한 일시적인 응답

+ +

{{Glossary("safe", "Unsafe")}} 요청이 서버의 상태를 수정할 경우, 사용자가 이를 우연히 재연할 수 있어서는 안됩니다. 일반적으로, 당신은 사용자가 {{HTTPMethod("PUT")}}, {{HTTPMethod("POST")}} 혹은 {{HTTPMethod("DELETE")}} 요청을 재전송하기를 바라지는 않을 겁니다. 만약 당신이 해당 요청의 결과로 지금 막 응답을 전송했다면, 단순히 새로고침 버전을 누르는 것만으로 요청은 재전송될 겁니다(아마도 확인 메시지 이후에).

+ +

이런 경우, 서버는 올바른 정보를 포함하게 될 {{HTTPStatus("303")}} (See Other) 요청을 회신할 수 있는데, 새로 고침 버튼이 눌린 경우, 안전하지 않은 요청이 재연되지 않고 동일한 페이지가 다시 디스플레이될 것입니다.

+ +

긴 요청에 대한 일시적인 응답

+ +

어떤 요청들은 때때로 후처리를 위해 예정되는 {{HTTPHeader("DELETE")}} 요청처럼, 서버 상에서 좀 더 많은 시간을 필요로 하는 경우가 있습니다. 이와 같은 경우에, 응답은 {{HTTPStatus("303")}} (See Other) 리다이렉트로, 어떤 동작이 예정되어 있고 진행률에 관해 알려주고 그 동작을 취소할 수 있도록 해주는 페이지로 리다이렉트됩니다.

+ +

일반 서버 내 리다이렉트 구성

+ +

Apache

+ +

리다이렉트는 서버 구성 파일 혹은 각 디렉토리의 .htaccess 내에서 설정될 수 있습니다.

+ +

mod_alias 모듈은 (기본값으로) {{HTTPStatus("302")}} 응답을 설정하는  Redirect 그리고 Redirect_Match 디렉티브를 가지고 있습니다:

+ +
<VirtualHost *:80>
+	ServerName example.com
+	Redirect / http://www.example.com
+</VirtualHost>
+
+ +

URL http://example.com/ 은 http://www.example.com/ 로 리다이렉트됩니다(하지만 http://example.com/other.html은 리다이렉트되지 않습니다).

+ +

Redirect_Match 도 똑같이 동작하지만 영향을 받은 URL 컬렉션 정의를 위해 정규 표현식을 받습니다:

+ +
RedirectMatch ^/images/(.*)$ http://images.example.com/$1
+ +

images/ 폴더 내 모든 문서들은 다른 도메인으로 리다이렉트될 것입니다.

+ +

일시적인 리다이렉트를 설정하고 싶지 않다면, 다른 리다이렉트를 설정하는데 여분의 파라메터(사용하고자 하는 HTTP 상태 코드 혹은 permanent 키워드)를 사용할 수 있습니다:

+ +
Redirect permanent / http://www.example.com
+Redirect 301 / http://www.example.com
+
+ +

mod_rewrite 모듈도 리다이렉티를 만드는데 사용될 수 있습니다. 이것은 약간 더 복잡한데, 사용은 약간 더 복잡합니다.

+ +

Nginx

+ +

Nginx에서는, 당신이 리다이렉트하고자 하는 컨텐츠에 대한 특정 서버 블록을 만들 수 있습니다:

+ +
server {
+	listen 80;
+	server_name example.com;
+	return 301 $scheme://www.example.com$request_uri;
+}
+ +

폴더 혹은 페이지의 하위 집합에만 적용되는 리다이렉트를 원한다면, rewrite 디렉티브를 사용하시기 바랍니다:

+ +
rewrite ^/images/(.*)$ http://images.example.com/$1 redirect;
+rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
+
+ +

IIS

+ +

IIS에서는, 리다이렉션 구성을 위해 <httpRedirect> 요소를 사용할 수 있습니다.

+ +

리다이렉션 루프

+ +

리다이렉션 루프는 성공적인 리다이렉션이 이전의 리다이렉션을 다시 따라갈 때 일어납니다. 다시 말해, 결코 끝나지 않으면, 끝까지 어떤 페이지도 볼 수 없는 루프가 존재한다는 말입니다.

+ +

대부분의 경우, 이런 문제는 서버 측 문제이며 서버가 이를 감지할 수 없다면, {{HTTPStatus("500")}} Internal Server Error를 회신할 것입니다. 서버 구성을 수정한 직후에 그런 오류를 보게 된다면, 그것은 리다이렉션 루프일 가능성이 큽니다.

+ +

때로는, 서버가 그것을 감지하지 않을 때도 있을 겁니다: 전체적인 그림을 모르는 몇 개의 서버에 리다이렉션 루프가 행해지기 때문입니다. 이런 경우, 브라우저가 이를 감지하고 오류 메시지를 보여줄 것입니다. 파이어폭스는 다음과 같이 디스플레이하게 됩니다:

+ +
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
+ +

반면, 크롬은 다음과 같이 디스플레이합니다:

+ +
This Webpage has a redirect loop
+ +

모든 경우에, 사용자가 할 수 있는 일은 그리 많지 않습니다(사용자 측에서 캐시 혹은 쿠키의 불일치와 같은 어떤 변화를 주지 않은 이상말이죠).

+ +

리다이렉션 루프는 사용자 경험을 완전히 망쳐놓기에 리다이렉션 루프를 피하는 것은 대단히 중요합니다.

-- cgit v1.2.3-54-g00ecf