aboutsummaryrefslogtreecommitdiff
path: root/files/ko/web/http/redirections
diff options
context:
space:
mode:
Diffstat (limited to 'files/ko/web/http/redirections')
-rw-r--r--files/ko/web/http/redirections/index.html256
1 files changed, 256 insertions, 0 deletions
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
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">URL 리다이렉션 혹은 URL 포워딩은 페이지 따위의 실제 리소스, 폼 혹은 전체 웹 애플리케이션이 다른 URL에 위치하고 있는 상태에서 링크를 존속시키는 기술입니다. HTTP는 많은 목표를 위해 사용되는 이런 동작을 수행하기 위해 특별한 종류의 응답인 <em>HTTP 리다이렉트</em>를 제공합니다: 사이트 유지관리가 진행 중인 상태에서의 일시적인 리다이렉션, 사이트 아키텍쳐의 변경 이후에도 외부 링크를 동작하는 상태로 유지시키기 위한 영구적인 리다이렉션, 파일 업로드 시 진행 상태 페이지 그리고 그 외의 수많은 리다이렉션들 ...</p>
+
+<h2 id="원칙">원칙</h2>
+
+<p>HTTP에서, 리다이렉션은 요청에 대해 특별한 응답(<em>리다이렉트</em>)을 전송함으로써 촉발됩니다. HTTP 리다이렉트는 <code>3xx</code> 상태 코드를 지닌 응답입니다. 리다이렉트 응답을 수신한 브라우저는, 제공된 새로운 URL을 사용하며 그것을 즉시 로드합니다: 대부분의 경우, 리다이렉션은 사용자에게는 보이지 않는데다가, 적은 성능 저하를 일으킵니다.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13785/HTTPRedirect.png"></p>
+
+<p>리다이렉트에는 몇 가지 유형이 있으며 세 가지 카테고리로 나누어집니다: 영속적, 일시적 그리고 특수 리다이렉션.</p>
+
+<h3 id="영속적인_리다이렉션">영속적인 리다이렉션</h3>
+
+<p>이 리다이렉션은 영원히 지속됨을 의미합니다. 원래의 URL이 더 이상 사용되지 않아야 하며 새로운 URL을 더 선호해야 함을 시사합니다. 검색 엔진 로봇은 그들의 인덱스 내에서 리소스에 대한 연관 URL의 갱신을 촉발시킵니다.</p>
+
+<table class="standard-table">
+ <thead>
+ <tr>
+ <th scope="col">코드</th>
+ <th scope="col">텍스트</th>
+ <th scope="col">메서드 핸들링</th>
+ <th scope="col">일반적인 유스케이스</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>301</code></td>
+ <td><code>Moved Permanently</code></td>
+ <td>{{HTTPMethod("GET")}} 메서드는 변경되지 않습니다.<br>
+ 다른 메서드들은  {{HTTPMethod("GET")}}로 변하거나 변하지 않을수도 있습니다.<sup><a href="#attr1">[1]</a></sup></td>
+ <td>웹 사이트의 재편성.</td>
+ </tr>
+ <tr>
+ <td><code>308</code></td>
+ <td><code>Permanent Redirect</code></td>
+ <td>메서드와 본문은 변하지 않습니다.</td>
+ <td>GET이 아닌 링크/동작을 지닌, 웹 사이트의 재편성.</td>
+ </tr>
+ </tbody>
+</table>
+
+<p><a id="attr1" name="attr1"></a>[1] 명세는 메서드 변경을 허용할 의도가 없으나, 사실 상 사용자 에이전트들이 그렇게 하고 있습니다. <code>308</code> 은 <code>GET</code>이 아닌 메서드를 사용할 때 동작의 애매모호함을 제거하고자 만들어졌습니다.</p>
+
+<h3 id="일시적인_리다이렉션">일시적인 리다이렉션</h3>
+
+<p>때때로 요청된 리소스는 그것의 표준 위치에서 접근할 수 없고 다른 위치에서 접근 가능한 경우가 있습니다. 이런 경우 일시적인 리다이렉트가 사용될 수 있습니다. 검색 엔진 로봇은 새로운, 일시적인 링크를 기억하지 못합니다. 일시적인 리다이렉션은 일시적인 진행율 페이지를 표시하고자 리소스를 만들고 갱신하며 삭제할 때 사용될 수 도 있습니다.</p>
+
+<table class="standard-table">
+ <thead>
+ <tr>
+ <th scope="col">코드</th>
+ <th scope="col">텍스트</th>
+ <th scope="col">메서드 핸들링</th>
+ <th scope="col">일반적인 유스 케이스</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>302</code></td>
+ <td><code>Found</code></td>
+ <td>{{HTTPMethod("GET")}} 메서드는 변경되지 않습니다.<br>
+ 다른 메서드들은  {{HTTPMethod("GET")}}로 변하거나 변하지 않을수도 있습니다.<sup><a href="#attr2">[2]</a></sup></td>
+ <td>웹 페이지가 예측하지 못한 이유로 일시적으로 이용 불가능할 때 가 있습니다. 그런 이유로, 검색 엔진은 그들의 링크를 갱신하지 않습니다.</td>
+ </tr>
+ <tr>
+ <td><code>303</code></td>
+ <td><code>See Other</code></td>
+ <td>{{HTTPMethod("GET")}} 메서드는 변경되지 않습니다.<br>
+ 다른 메서들은 <code>GET</code> 메서드로 <em>변경됩니다</em>(본문을 잃게 됩니다).</td>
+ <td>동작을 다시 촉발시키는 페이지 리프레시를 막기 위해 {{HTTPMethod("PUT")}} 혹은  {{HTTPMethod("POST")}} 뒤에 사용됩니다.</td>
+ </tr>
+ <tr>
+ <td><code>307</code></td>
+ <td><code>Temporary Redirect</code></td>
+ <td>메서드와 본문은 변경되지 않습니다.</td>
+ <td>웹 페이지가 예측하지 못한 이유로 일시적으로 이용 불가능할 때 가 있습니다. 그런 이유로, 검색 엔진은 그들의 링크를 갱신하지 않습니다. GET이 아닌 링크/동작이 사이트에서 이용 가능할 때 <code>302</code>보다 더 좋습니다.</td>
+ </tr>
+ </tbody>
+</table>
+
+<p><a id="attr2" name="attr2"></a>[2] 명세에는 메서드 변경을 허용할 의도가 없으나, 실질적으로 사용자 에이전트들이 그렇게 하고 있습니다. <code>307</code> 은 <code>GET</code>이 아닌 메서드들을 사용하는 경우 동작의 애매모호함을 제거하기 위해 만들어집니다.</p>
+
+<h3 id="특수_리다이렉션">특수 리다이렉션</h3>
+
+<p>이런 보통 리다이렉션과 더불어, 특별한 두 가지 리다이렉션이 더 있습니다. {{HTTPStatus("304")}} (수정되지 않음)은 (오랜된)로컬에 캐시된 복사본으로 페이지를 리다이렉트시키며, {{HTTPStatus("300")}} (다중 선택)은 수동 리다이렉션입니다:브라우저에 의해 웹 페이지로 표현되는 분문은 가능한 리다이렉션을 나열하며 사용자는 그 중 하나를 선택하기 위해 클릭합니다.</p>
+
+<table class="standard-table">
+ <thead>
+ <tr>
+ <th scope="col">코드</th>
+ <th scope="col">텍스트</th>
+ <th scope="col">일반적인 유스케이스</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>300</code></td>
+ <td><code>Multiple Choice</code></td>
+ <td>이런 경우가 많지는 않습니다: 본문의 HTML 페이지 내에 선택지가 나열됩니다. {{HTTPStatus("200")}} <code>OK</code> 상태와 함께 서브될 수 있습니다.</td>
+ </tr>
+ <tr>
+ <td><code>304</code></td>
+ <td><code>Not Modified</code></td>
+ <td>캐시 리프레시: 캐시 값이 여전히 사용 가능할 정도로 신선함을 가리킵니다.</td>
+ </tr>
+ </tbody>
+</table>
+
+<h2 id="리다이렉션을_명시하는_대체_방법">리다이렉션을 명시하는 대체 방법</h2>
+
+<p>HTTP 리다이렉트가 리다이렉션을 정의하는 유일한 방법은 아닙니다. 두 개의 다른 방법이 존재합니다: {{HTMLElement("meta")}} 엘리먼트를 사용하는 HTML 리다이렉션과 <a href="/en-US/docs/Web/API/Document_Object_Model">DOM</a>을 사용하는 자바스크립트 리다이렉션이 있습니다.</p>
+
+<h3 id="HTML_리다이렉션">HTML 리다이렉션</h3>
+
+<p>HTTP 리다이렉트는 리다이렉션을 만드는 가장 좋은 방법이지만, 때때로 웹 개발자는 서버에 대한 제어권을 가지고 있지 않거나 그것을 구성할 수 없는 경우가 있습니다. 이런 특수한 상황들 때문에, 웹 개발자들은 <code>refresh</code>를 설정하기 위해 페이지의 {{HTMLElement("head")}} 내에 {{HTMLElement("meta")}} 엘리먼트와 {{htmlattrxref("http-equiv", "meta")}} 속성으로 HTML 페이지를 만들 수 있습니다. 해당 페이지를 디스플레이할 때, 브라우저는 이 엘리먼트를 발견하고 표시된 페이지로 이동할 것입니다.</p>
+
+<pre class="brush: html notranslate">&lt;head&gt;
+ &lt;meta http-equiv="refresh" content="0;URL='http://www.example.com/'" /&gt;
+&lt;/head&gt;
+</pre>
+
+<p>{{htmlattrxref("content")}} 속성은 주어진 URL로 리다이렉트 하기 이전에 브라우저가 얼마만큼의 시간(초)을 기다려야 하는지를 나타내는 숫자로 시작됩니다. 더 나은 접근성을 위해 항상 0으로 설정하시기 바랍니다.</p>
+
+<p>두 말할 필요없이, 이 메서드는 HTML 페이지(혹은 그와 유사한 무언가)에서만 동작하며 이미지나 다른 어떤 종류의 컨텐츠에 대해서 사용될 수 없습니다.</p>
+
+<div class="note">
+<p>이런 리다이렉션들이 브라우저에서 뒤로 가기 버튼을 무용지물로 만든다는 것을 기억하시기 바랍니다: 해당 헤더가 있는 페이지로 다시 돌아갈 수 있는지만 즉시 앞으로 이동하게 될겁니다.</p>
+</div>
+
+<h3 id="자바스크립트_리다이렉션">자바스크립트 리다이렉션</h3>
+
+<p>자바스크립트 내에서의 리다이렉션은 {{domxref("window.location")}} 프로퍼티에 값을 설정해서 만들어지며 새로운 페이지가 로드됩니다.</p>
+
+<pre class="brush: js notranslate">window.location = "http://www.example.com/";</pre>
+
+<p>HTML 리다이렉션처럼, 모든 리소스에서 동작하는 것은 아니며, 명백하게 자바스크립트를 실행한 클라이언트 상에서만 동작합니다. 하지만 다른점은, 예를 들어 어떤 조건이 충족되는 경우에만 리다이렉션을 촉발시킬 수 있다는 점에서 더 많은 가능성을 가지고 있습니다.</p>
+
+<h3 id="우선_순위">우선 순위</h3>
+
+<p>URL 리다이렉션에 대한 세 가지 가능성이 있기에, 몇 가지 방법이 동시에 지정될 수 있는데, 어떤 것이 먼저 적용될까요? 우선 순위는 다음과 같습니다:</p>
+
+<ol>
+ <li>페이지가 읽힌 적도 없고 전송된 적도 없는 경우, HTTP 리다이렉트가 항상 먼저 실행됩니다.</li>
+ <li>어떤 HTTP 리다이렉트로 없는 경우에, HTML 리다이렉트 ({{HTMLElement("meta")}})가 실행됩니다.</li>
+ <li>자바스크립트 리다이렉트는 최후의 순단으로써 사용되며, 클라이언트 측에서 자바스크립트를 활성화시킨 경우에만 사용할 수 있습니다.</li>
+</ol>
+
+<p>가능한 경우, 항상 HTTP 리다이렉트를 사용해야 하며, {{HTMLElement("meta")}} 엘리먼트를 사용해서는 안됩니다. 만약 개발자가 HTTP 리다이렉트를 변경하고 HTML 리다이렉트를 잊는다면, 리다이렉트는 더 이상 동일한 한 것이 아니거나, 무한 루프로 종료되거나 다른 악몽이 시작될 수도 있습니다.</p>
+
+<h2 id="유스_케이스">유스 케이스</h2>
+
+<p>리다이렉트에 대한 많은 유스 케이스들이 존재하지만, 모든 리다이렉트들이 성능과 직결되므로, 리다이렉트의 사용은 최소한으로 유지되어야 합니다.</p>
+
+<h3 id="도메인_앨리어싱">도메인 앨리어싱</h3>
+
+<p>이상적으로, 하나의 로케이션이 존재하고, 그래서 하나의 리소스에 대해 하나의 URL이 존재한다고 가정하겠습니다. 그러나 하나의 리소스에 대한 대체 이름을 갖고자 할 때가 있을 수 있습니다 (www 접두사를 갖거나 갖지 않는 몇몇 도메인 혹은 URL을 더 짧고 기억하기 쉽도록하는 등...). 이런 경우, 리소스를 복제하기 보다는 실제 (정식) URL에 대한 리다이렉트를 사용하는 것이 더 유용합니다.</p>
+
+<p>도메인 앨리어싱을 하는 경우는 다음과 같습니다.</p>
+
+<ul>
+ <li>사이트 범위 확장. 당신의 사이트가 <code>www.example.com</code> 도메인을 가지고 있을 때 <code>example.com</code>을 통한 접근도 가능한 경우가 가장 흔한 경우입니다. <code>example.com</code> 페이지를  <code>www.example.com</code> 로 리다이렉션하는 것이 이 경우에 해당됩니다. 일반적으로 사용되는 별칭 혹은, 도메인 이름에 빈번히 일어나는 오자를 제공할 수도 있습니다.</li>
+ <li>다른 도메인으로의 이동. 예를 들어, 당신의 회사가 이름을 변경했고 이전 이름으로 검색하는 경우 여전히 회사의 옛날 이름으로 웹 사이트를 사용하는 사람들이 새로운 이름의 사이트를 이용하길 바라는 경우에 해당됩니다.</li>
+ <li>HTTPS 강제. 사이트에 대한 HTTP 버전 요청은 사이트의 HTTPS 버전으로 리다이렉트될 것입니다.</li>
+</ul>
+
+<h3 id="링크_유지하기">링크 유지하기</h3>
+
+<p>웹 사이트를 다시 만들때, 리소스의 URL이 변경되기 마련입니다. 새로운 네이밍 계획과 일치하도록 웹 사이트의 내부 링크를 갱신할 수 있는 경우조차도, 외부 리소스에 의해 사용되는 URL에 대해서는 어쩔 수가 없습니다. 그들은 당신에게 소중한 사용자이므로(또 SEO에 도움이 되길 바라는 마음으로) 해당 링크를 깨뜨리고 싶지 않을 것이기에, 이전 URL에서 새로운 URL로의 리다이렉트를 설정하려 할 겁니다.</p>
+
+<div class="note">
+<p>이 기술 또한 내부 링크에 대해서 동작하므로, 내부 리다이렉트는 피해야 할 겁니다. 리다이렉트는 상당한 성능 비용이 드므로(추가적인 HTTP 요청이 수행되므로) 내부 링크를 바로잡아 내부 다이렉트를 피할 수 있다면 해당 링크를 수정해야 합니다.</p>
+</div>
+
+<h3 id="안전하지_않은_요청에_대한_일시적인_응답">안전하지 않은 요청에 대한 일시적인 응답</h3>
+
+<p>{{Glossary("safe", "Unsafe")}} 요청이 서버의 상태를 수정할 경우, 사용자가 이를 우연히 재연할 수 있어서는 안됩니다. 일반적으로, 당신은 사용자가 {{HTTPMethod("PUT")}}, {{HTTPMethod("POST")}} 혹은 {{HTTPMethod("DELETE")}} 요청을 재전송하기를 바라지는 않을 겁니다. 만약 당신이 해당 요청의 결과로 지금 막 응답을 전송했다면, 단순히 새로고침 버전을 누르는 것만으로 요청은 재전송될 겁니다(아마도 확인 메시지 이후에).</p>
+
+<p>이런 경우, 서버는 올바른 정보를 포함하게 될 {{HTTPStatus("303")}} (See Other) 요청을 회신할 수 있는데, 새로 고침 버튼이 눌린 경우, 안전하지 않은 요청이 재연되지 않고 동일한 페이지가 다시 디스플레이될 것입니다.</p>
+
+<h3 id="긴_요청에_대한_일시적인_응답">긴 요청에 대한 일시적인 응답</h3>
+
+<p>어떤 요청들은 때때로 후처리를 위해 예정되는 {{HTTPHeader("DELETE")}} 요청처럼, 서버 상에서 좀 더 많은 시간을 필요로 하는 경우가 있습니다. 이와 같은 경우에, 응답은 {{HTTPStatus("303")}} (See Other) 리다이렉트로, 어떤 동작이 예정되어 있고 진행률에 관해 알려주고 그 동작을 취소할 수 있도록 해주는 페이지로 리다이렉트됩니다.</p>
+
+<h2 id="일반_서버_내_리다이렉트_구성">일반 서버 내 리다이렉트 구성</h2>
+
+<h3 id="Apache">Apache</h3>
+
+<p>리다이렉트는 서버 구성 파일 혹은 각 디렉토리의 <code>.htaccess</code> 내에서 설정될 수 있습니다.</p>
+
+<p><a href="https://httpd.apache.org/docs/current/mod/mod_alias.html">mod_alias</a> 모듈은 (기본값으로) {{HTTPStatus("302")}} 응답을 설정하는  <code>Redirect</code> 그리고 <code>Redirect_Match</code> 디렉티브를 가지고 있습니다:</p>
+
+<pre class="notranslate">&lt;VirtualHost *:80&gt;
+ ServerName example.com
+ Redirect / http://www.example.com
+&lt;/VirtualHost&gt;
+</pre>
+
+<p>URL <code>http://example.com/</code> 은 <code>http://www.example.com/</code> 로 리다이렉트됩니다(하지만 <code>http://example.com/other.html</code>은 리다이렉트되지 않습니다).</p>
+
+<p><code>Redirect_Match</code> 도 똑같이 동작하지만 영향을 받은 URL 컬렉션 정의를 위해 정규 표현식을 받습니다:</p>
+
+<pre class="notranslate">RedirectMatch ^/images/(.*)$ http://images.example.com/$1</pre>
+
+<p><code>images/</code> 폴더 내 모든 문서들은 다른 도메인으로 리다이렉트될 것입니다.</p>
+
+<p>일시적인 리다이렉트를 설정하고 싶지 않다면, 다른 리다이렉트를 설정하는데 여분의 파라메터(사용하고자 하는 HTTP 상태 코드 혹은 <code>permanent</code> 키워드)를 사용할 수 있습니다:</p>
+
+<pre class="notranslate">Redirect permanent / http://www.example.com
+Redirect 301 / http://www.example.com
+</pre>
+
+<p><a href="http://httpd.apache.org/docs/current/mod/mod_rewrite.html">mod_rewrite</a> 모듈도 리다이렉티를 만드는데 사용될 수 있습니다. 이것은 약간 더 복잡한데, 사용은 약간 더 복잡합니다.</p>
+
+<h3 id="Nginx">Nginx</h3>
+
+<p>Nginx에서는, 당신이 리다이렉트하고자 하는 컨텐츠에 대한 특정 서버 블록을 만들 수 있습니다:</p>
+
+<pre class="notranslate">server {
+ listen 80;
+ server_name example.com;
+ return 301 $scheme://www.example.com$request_uri;
+}</pre>
+
+<p>폴더 혹은 페이지의 하위 집합에만 적용되는 리다이렉트를 원한다면, <code>rewrite</code> 디렉티브를 사용하시기 바랍니다:</p>
+
+<pre class="notranslate">rewrite ^/images/(.*)$ http://images.example.com/$1 redirect;
+rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
+</pre>
+
+<h3 id="IIS">IIS</h3>
+
+<p>IIS에서는, 리다이렉션 구성을 위해 <code><a href="https://www.iis.net/configreference/system.webserver/httpredirect">&lt;httpRedirect&gt;</a></code> 요소를 사용할 수 있습니다.</p>
+
+<h2 id="리다이렉션_루프">리다이렉션 루프</h2>
+
+<p>리다이렉션 루프는 성공적인 리다이렉션이 이전의 리다이렉션을 다시 따라갈 때 일어납니다. 다시 말해, 결코 끝나지 않으면, 끝까지 어떤 페이지도 볼 수 없는 루프가 존재한다는 말입니다.</p>
+
+<p>대부분의 경우, 이런 문제는 서버 측 문제이며 서버가 이를 감지할 수 없다면, {{HTTPStatus("500")}} <code>Internal Server Error</code>를 회신할 것입니다. 서버 구성을 수정한 직후에 그런 오류를 보게 된다면, 그것은 리다이렉션 루프일 가능성이 큽니다.</p>
+
+<p>때로는, 서버가 그것을 감지하지 않을 때도 있을 겁니다: 전체적인 그림을 모르는 몇 개의 서버에 리다이렉션 루프가 행해지기 때문입니다. 이런 경우, 브라우저가 이를 감지하고 오류 메시지를 보여줄 것입니다. 파이어폭스는 다음과 같이 디스플레이하게 됩니다:</p>
+
+<pre class="bz_comment_text notranslate" id="comment_text_0">Firefox has detected that the server is redirecting the request for this address in a way that will never complete.</pre>
+
+<p>반면, 크롬은 다음과 같이 디스플레이합니다:</p>
+
+<pre class="notranslate">This Webpage has a redirect loop</pre>
+
+<p>모든 경우에, 사용자가 할 수 있는 일은 그리 많지 않습니다(사용자 측에서 캐시 혹은 쿠키의 불일치와 같은 어떤 변화를 주지 않은 이상말이죠).</p>
+
+<p>리다이렉션 루프는 사용자 경험을 완전히 망쳐놓기에 리다이렉션 루프를 피하는 것은 대단히 중요합니다.</p>