diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:42:17 -0500 |
|---|---|---|
| committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:42:17 -0500 |
| commit | da78a9e329e272dedb2400b79a3bdeebff387d47 (patch) | |
| tree | e6ef8aa7c43556f55ddfe031a01cf0a8fa271bfe /files/ko/web/http/basics_of_http | |
| parent | 1109132f09d75da9a28b649c7677bb6ce07c40c0 (diff) | |
| download | translated-content-da78a9e329e272dedb2400b79a3bdeebff387d47.tar.gz translated-content-da78a9e329e272dedb2400b79a3bdeebff387d47.tar.bz2 translated-content-da78a9e329e272dedb2400b79a3bdeebff387d47.zip | |
initial commit
Diffstat (limited to 'files/ko/web/http/basics_of_http')
7 files changed, 1257 insertions, 0 deletions
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> |