Chapter 1. Overview of HTTP
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Media Types
Because the Internet hosts many thousands of different data types, HTTP carefully tags each object being transported through the Web with a data format label called a MIME type. MIME (Multipurpose Internet Mail Extensions) was originally designed to solve problems encountered in moving messages between different electronic mail systems. MIME worked so well for email that HTTP adopted it to describe and label its own multimedia content.
-> 인터넷은 수천 가지의 데이터 타입을 향유하고 있습니다. HTTP는 MIME이라 불리는 데이터 포맷 라벨을 통해 웹을 통해 전달된 각각의 객체를 나타냅니다.
-> 초창기의 MIME(Multipurpose Internet Mail Extensions)은 서로 다른 전자메일 시스템 사이에서 메시지를 주고받는 과정에서 직면한 문제를 해결하기 위해 고안되었습니다.
-> MIME이 이메일에서 잘 작동하였기 때문에 HTTP는 멀티미디어 콘텐츠를 표현하고 라벨링하기 위해 MIME을 채택하였습니다.
Web servers attach a MIME type to all HTTP object data (see Figure 1-3). When a web browser gets an object back from a server, it looks at the associated MIME type to see if it knows how to handle the object. Most browsers can handle hundreds of popular object types: displaying image files, parsing and formatting HTML files, playing audio files through the computer’s speakers, or launching external plug-in software to handle special formats.
-> 웹 서버는 MIME 타입을 모든 HTTP 객체 데이터에 붙입니다. (Figure 1-3)
-> 웹 브라우저는 서버로부터 객체를 돌려받을 때, 그 객체를 처리하는 방법을 알고 있는지 확인하는 MIME 타입과 함께 돌려받습니다.
-> 대부분의 브라우저는 자주 사용되는 수백 개의 객체 타입을 처리할 수 있습니다 : 이미지 파일 보여주기, HTML 파일 파싱하거나 포맷하기, 컴퓨터 스피커를 통해 오디오 파일 재생하기, 특별한 포맷을 처리하기 위해 외부의 플러그인 실행하기 등
A MIME type is a textual label, represented as a primary object type and a specific subtype, separated by a slash. For example:
• An HTML-formatted text document would be labeled with type text/html.
• A plain ASCII text document would be labeled with type text/plain.
• A JPEG version of an image would be image/jpeg.
• A GIF-format image would be image/gif.
• An Apple QuickTime movie would be video/quicktime.
• A Microsoft PowerPoint presentation would be application/vnd.ms-powerpoint.
There are hundreds of popular MIME types, and many more experimental or limited-use types. A very thorough MIME type list is provided in Appendix D.
-> MIME 타입은 텍스트로 된 라벨입니다. 주요한 객체의 유형과 구체적인 포맷을 슬래시로 구분하여 나타냅니다.
- HTML 포맷의 문서는 "text/html"로 표기
- 아스키코드 문서는 "text/plain"으로 표기
- JPEG 이미지는 "image/jped"로 표기
- GIF 이미지는 "image/gif"로 표기
- Apple QuickTime Movie는 "video/quicktime"으로 표기
- Microsoft PowerPoint Presentation은 "application/vnd.ms-powerpoint"로 표기
-> 이처럼 수백 가지의 MIME 타입이 존재하고, 실험적이거나 제한적으로 사용되는 타입들도 여러 가지가 있습니다. 자세한 MIME 타입 리스트는 Appendix D를 확인하십시오.
URIs
Each web server resource has a name, so clients can point out what resources they are interested in. The server resource name is called a uniform resource identifier, or URI. URIs are like the postal addresses of the Internet, uniquely identifying and locating information resources around the world.
Here’s a URI for an image resource on Joe’s Hardware store’s web server:
http://www.joes-hardware.com/specials/saw-blade.gif
-> 각각의 웹 서버 리소스는 이름을 갖고 있습니다. 따라서 클라이언트는 그들이 관심을 갖고 있는 리소스가 무엇인지 나타낼 수 있습니다.
-> 이때 서버 리소스의 이름을 URI(Uniform Resource Identifier)라고 부릅니다.
-> URI는 인터넷의 우편 주소와 같습니다. 전세계의 리소스를 식별하고 정보의 위치를 파악하게 합니다.
-> "Joe's Hardware Store"의 웹 서버에 위치한 이미지 리소스를 접근하는 URI는 다음과 같습니다 : http://www.joes-hardware.com/specials/saw-blade.gif
Figure 1-4 shows how the URI specifies the HTTP protocol to access the saw-blade GIF resource on Joe’s store’s server. Given the URI, HTTP can retrieve the object. URIs come in two flavors, called URLs and URNs. Let’s take a peek at each of these types of resource identifiers now.
-> Figure 1-4는 URI가 "Joe's Store's Store"의 서버에 위치한 "saw-blade" GIF 리소스에 접근하기 위해 HTTP 프로토콜을 구체화하는 방식을 보여줍니다.
-> URI가 주어지면, HTTP는 객체를 찾을 수 있습니다.
-> URI는 URL과 URN의 두 가지 형태로 주어집니다.
-> 지금부터 각각의 리소스 식별자 형태에 대해 살펴보겠습니다.
URLs
The uniform resource locator (URL) is the most common form of resource identifier. URLs describe the specific location of a resource on a particular server. They tell you exactly how to fetch a resource from a precise, fixed location. Figure 1-4 shows how a URL tells precisely where a resource is located and how to access it. Table 1-1 shows a few examples of URLs.
-> URL(Uniform Resource Locator)은 리소스 식별자의 가장 기본적인 형태입니다.
-> URL은 리소스가 특정 서버의 어느 곳에 위치해있는지 구체적으로 나타내며, 정확히 고정된 위치에서 리소스를 가져오는 방식을 명확하게 전달합니다.
-> Figure 1-4는 URL이 리소스가 어디에 위치해 있고 어떻게 접근할 수 있는지를 명확하게 전달하는 법을 보여줍니다.
-> Tale 1-1은 URL의 몇 가지 예시를 나타냅니다.
Most URLs follow a standardized format of three main parts:
• The first part of the URL is called the scheme, and it describes the protocol used to access the resource. This is usually the HTTP protocol (http://).
• The second part gives the server Internet address (e.g., www.joes-hardware.com).
• The rest names a resource on the web server (e.g., /specials/saw-blade.gif ).
Today, almost every URI is a URL.
-> 대부분의 URL은 3가지 주요 부분에서 표준화된 형태를 따릅니다.
- URL의 첫 번째 부분(Scheme) : 리소스를 접근하는 데 사용되는 프로토콜 표현, 주로 HTTP 프로토콜(http://)
- URL의 두 번째 부분 : 서버의 인터넷 주소(www.joes-hardware.com)
- URL의 나머지 부분 : 웹 서버상의 리소스(/specials/saw-blade.gif)
-> 오늘날, 거의 대부분의 URI는 URL입니다.
URNs
The second flavor of URI is the uniform resource name, or URN. A URN serves as a unique name for a particular piece of content, independent of where the resource currently resides. These location-independent URNs allow resources to move from place to place. URNs also allow resources to be accessed by multiple network access protocols while maintaining the same name.
-> URI의 두 번째 형태는 URN(Uniform Resource Name)입니다.
-> URN은 콘텐츠의 일부분에 대하여 특정한 이름을 붙입니다. 이것은 현재 리소스가 어디에 위치하고 있는지와는 관련이 없습니다.
-> 이처럼 위치에 독립적인 URN은 리소스가 특정 위치에서 다른 위치로 이동하는 것을 허용합니다.
-> 또한 리소스가 동일한 이름을 유지하는 한 여러 네트워크 접근 프로토콜에 의해 접근될 수 있습니다.
For example, the following URN might be used to name the Internet standards document “RFC 2141” regardless of where it resides (it may even be copied in several places):
urn:ietf:rfc:2141
-> 예를 들어, 다음 URN은 인터넷 표준 문서 "RFC 2141"을 저장된 위치와 관계없이 명명하기 위해 사용되었습니다(아마 이 문서는 여기저기 복사되었을 것입니다) : urn:ietf:rfc:2141
URNs are still experimental and not yet widely adopted. To work effectively, URNs need a supporting infrastructure to resolve resource locations; the lack of such an infrastructure has also slowed their adoption. But URNs do hold some exciting promise for the future. We’ll discuss URNs in a bit more detail in Chapter 2, but most of the remainder of this book focuses almost exclusively on URLs.
-> URN은 여전히 실험적이며 아직까지 널리 사용되지 않습니다.
-> URN이 효과적으로 작동하기 위해서는 리소스 위치 문제를 해결하기 위한 인프라가 뒷받침되어야 합니다; 이러한 인프라의 결함이 URN의 상용화를 늦추고 있기도 합니다.
-> 그러나 URN은 분명 미래에 대한 흥미로운 약속을 갖고 있습니다. Chapter 2에서 URN에 대해 더 자세히 이야기하겠지만, 이 책의 나머지 대부분은 오직 URL에만 초점을 맞추고 있습니다.
Unless stated otherwise, we adopt the conventional terminology and use URI and URL interchangeably for the remainder of this book.
-> 특별한 언급이 없는 한, 우리는 기존의 용어를 채택하고 이 책의 나머지 부분에서는 URI와 URL을 혼용할 것입니다.
🧡 요약 정리 🧡
MIME (Multipurpose Internet Mail Extensions)
- HTTP에서 멀티미디어를 표현하기 위해 사용되는 텍스트 라벨
- 표기 : 객체의 유형/구체적인 포맷 (ex. text/plain)
- HTTP : 객체 + MIME 타입(객체 처리 방법 확인)
URI (Uniform Resource Identifier)
- 리소스를 식별하고 정보의 위치를 파악하기 위한 이름
- URL(Uniform Resource Location) : 리소스의 위치 정보 포함 (프로토콜 + 서버주소 + 리소스명)
- URN(Uniform Resource Name) : 리소스의 위치 정보 포함 X, 콘텐츠의 일부분에 대해 특정한 이름을 붙인 것
- 오늘날 URL을 주로 사용
💛 감상 💛
- 웹 브라우저가 객체를 처리하는 방법을 알 수 있게 하기 위해 콘텐츠 데이터와 MIME 타입을 함께 전달한다는 사실을 알게 되었다.
- 항상 헷갈렸던 URI와 URL, URN 개념이 깔끔하게 정리가 되었다. 이들 사이의 포함 관계도 명확하게 이해할 수 있었다.
