---

Chapter 2. URLs and Resources

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

❤️ 원문 번역 ❤️

Paths

The path component of the URL specifies where on the server machine the resource lives. The path often resembles a hierarchical filesystem path. For example:

http://www.joes-hardware.com:80/seasonal/index-fall.html

• URL의 Path(경로) 구성요소는 리소스가 존재하는 서버의 특정 위치를 가리킵니다.

• Path는 파일시스템의 계층적인 경로와 유사합니다.
  -> http://www.joes-hardware.com:80/seasonal/index-fall.html
  

The path in this URL is “/seasonal/index-fall.html”, which resembles a filesystem path on a Unix filesystem. The path is the information that the server needs to locate the resource.* The path component for HTTP URLs can be divided into path segments separated by “/” characters (again, as in a file path on a Unix filesystem). Each path segment can have its own params component.

• 여기서 URL의 Path는 "/seasonal/index-fall.html"입니다. 이는 Unix 파일시스템 파일 경로와 유사합니다.

• Path는 서버가 리소스를 가리킬 때 요구되는 정보입니다.

• * HTTP URL의 Path 구성 요소는 "/" 문자를 통해 각각의 세그먼트들로 분해됩니다.

• 각각의 Path 세그먼트는 고유의 Params 구성 요소를 가질 수 있습니다.

---

Parameters

For many schemes, a simple host and path to the object just aren’t enough. Aside from what port the server is listening to and even whether or not you have access to the resource with a username and password, many protocols require more information to work.

• 여러 가지 Scheme에 대하여, 단순히 객체로 향하는 호스트와 경로만으로는 충분하지 않습니다.

• 수신 중인 서버 포트가 무엇인지 유저명과 패스워드를 가지고 해당 리소스에 접근할 수 있는지와 같은 정보를 차치하고도, 프로토콜이 동작하기 위해서는 보다 많은 정보를 요구합니다.

Applications interpreting URLs need these protocol parameters to access the resource. Otherwise, the server on the other side might not service the request or, worse yet, might service it wrong. For example, take a protocol like FTP, which has two modes of transfer, binary and text. You wouldn’t want your binary image transferred in text mode, because the binary image could be scrambled.

• URL을 해석하는 애플리케이션은 리소스에 접근하기 위한 프로토콜 파라미터가 필요합니다.

• 프로토콜 파라미터가 없다면 다른 곳에 위치한 서버가 요청을 처리하지 못하거나 잘못된 서비스를 제공할지도 모릅니다.

• 예를 들어, 바이너리와 텍스트의 두 가지 전송 모드를 보유한 FTP와 같은 프로토콜을 사용한다고 가정합니다.

• 여러분은 이진 이미지가 텍스트 모드로 전송되기를 원하지 않을 것입니다. 이진 이미지가 섞일 수도 있기 때문입니다.

To give applications the input parameters they need in order to talk to the server correctly, URLs have a params component. This component is just a list of name/value pairs in the URL, separated from the rest of the URL (and from each other) by “;” characters. They provide applications with any additional information that they need to access the resource. For example:

ftp://prep.ai.mit.edu/pub/gnu;type=d

• 애플리케이션에게 입력 파라미터를 전달하기 위해 URL은 서버에게 정확히 이야기할 필요가 있습니다. 따라서 URL은 파라미터 구성 요소를 가집니다.

• 이 구성 요소는 URL에서 name/value 쌍 배열로 표현됩니다. 서로 다른 name/value쌍과 URL의 나머지 부분과는 ";" 문자를 통해 구분됩니다.

• 파라미터는 애플리케이션에게 리소스에 접근하는 데 필요한 모든 부가적인 정보들을 제공합니다.
  -> ftp://prep.ai.mit.edu/pub/gnu;type=d
  

In this example, there is one param, type=d, where the name of the param is “type”
and its value is “d”.

• 예제에서는 "type=d"라는 하나의 파라미터를 가지고 있습니다.

• 파라미터의 name은 "type"이고, value는 "d"입니다.

As we mentioned earlier, the path component for HTTP URLs can be broken into path segments. Each segment can have its own params. For example:
http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true

• 앞서 이야기했던 것처럼, HTTP URL의 Path 구성 요소는 각각의 세그먼트들로 나누어질 수 있습니다.

• 그리고 각각의 세그먼트는 고유한 파라미터를 가질 수 있습니다.
  -> http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
  

In this example there are two path segments, hammers and index.html. The hammers path segment has the param sale, and its value is false. The index.html segment has the param graphics, and its value is true.

• 예제는 두 개의 Path 세그먼트인 hammers와 index.html을 가집니다.

• hammers 세그먼트는 파라미터로 sale을 가지고 있고 그 값은 false입니다.

• index.html 세그먼트는 graphics 파라미터를 가지고 있고 그 값은 true입니다.

---

Query Strings

Some resources, such as database services, can be asked questions or queries to narrow down the type of resource being requested.

• 데이터베이스 서비스와 같은 몇몇 리소스들은 질문이나 쿼리를 요구할 수 있습니다.

• 쿼리는 요청받은 리소스의 유형을 좁혀나가기 위해 필요합니다.

Let’s say Joe’s Hardware store maintains a list of unsold inventory in a database and allows the inventory to be queried, to see whether products are in stock. The following URL might be used to query a web database gateway to see if item number 12731 is available:

http://www.joes-hardware.com/inventory-check.cgi?item=12731

• Joe's Hardware Store가 데이터베이스에 판매되지 않은 재고의 목록을 유지 및 관리하고 있다고 가정합니다. 이때 요청받은 재고가 남아있는지 확인할 수 있습니다.

• 다음 URL은 웹 데이터베이스 게이트웨이에게 12731번 재고가 남아있는지 확인하기 위한 쿼리에 사용될 것입니다.
  -> http://www.joes-hardware.com/inventory-check.cgi?item=12731
  

For the most part, this resembles the other URLs we have looked at. What is new is everything to the right of the question mark (?). This is called the query component. The query component of the URL is passed along to a gateway resource, with the path component of the URL identifying the gateway resource. Basically, gateways can be thought of as access points to other applications (we discuss gateways in detail in Chapter 8).

• 대부분은 지금까지 봐온 다른 URL과 유사합니다.

• 새로 추가된 부분은 물음표 다음에 이어지는 부분입니다.

• 이것이 바로 쿼리입니다.

• URL의 쿼리는 구성 요소는 게이트웨이 리소스를 식별하는 URL의 Path 구성 요소와 함께 게이트웨이 리소스에 전달됩니다.

• 일반적으로, 게이트웨이는 다른 애플리케이션의 액세스 포인트로 여겨집니다.
  (게이트웨이는 Chapter 8에서 자세히 다룹니다.)
  

Figure 2-2 shows an example of a query component being passed to a server that is acting as a gateway to Joe’s Hardware’s inventory-checking application. The query is checking whether a particular item, 12731, is in inventory in size large and color blue.

• Figure 2-2는 서버에 전달되는 쿼리의 예시입니다. 해당 서버는 Joe's Hardware의 재고 확인 애플리케이션의 게이트웨이로써 동작합니다.

• 쿼리는 12731이라는 특정 품목 중 파란색이고 large 사이즈인 재고가 남아있는지 확인하고 있습니다.

There is no requirement for the format of the query component, except that some characters are illegal, as we’ll see later in this chapter. By convention, many gateways expect the query string to be formatted as a series of “name=value” pairs, separated by “&” characters:

http://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue

In this example, there are two name/value pairs in the query component: item=12731
and color=blue.

• 쿼리의 형태는 허용되지 않는 몇몇 문자들을 제외하고는 특별한 요구사항이 없습니다. 허용 문자들에 대해서는 이 챕터의 나중 부분에서 다룰 것입니다.

• 게이트웨이는 일반적으로 "&" 문자로 구별되는 "name=value" 쌍으로 이루어진 쿼리문을 요구합니다.
  -> http://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue

• 이 예제에서는 item=12731, color=blue 두 개의 name/value 쌍으로 이루어진 쿼리가 사용되었습니다.

---

Fragments

Some resource types, such as HTML, can be divided further than just the resource level. For example, for a single, large text document with sections in it, the URL for the resource would point to the entire text document, but ideally you could specify the sections within the resource.

• HTML과 같은 몇 가지 리소스 유형은 리소스 수준 이상으로 분리 가능합니다.

• 예를 들어 여러 개의 섹션으로 나누어진 하나의 거대한 텍스트 문서가 있다고 합니다. 리소스의 URL은 텍스트 문서 전체를 가리킬 수도 있지만, 이상적으로는 이 리소스 내의 특정 섹션을 가리킬 수도 있을 것입니다.

To allow referencing of parts or fragments of a resource, URLs support a frag component to identify pieces within a resource. For example, a URL could point to a particular image or section within an HTML document.

• 리소스의 일부분을 참조하기 위해 URL은 Frag 구성 요소를 지원합니다. Frag는 리소스의 각 부분을 식별하는 역할을 합니다.

• 예를 들어 URL은 HTML 문서에서 특정 이미지나 섹션을 가리킬 수 있습니다.

A fragment dangles off the right-hand side of a URL, preceded by a # character. For example:

http://www.joes-hardware.com/tools.html#drills

• Frag는 URL의 오른편에 위치해 있고, "#" 문자 뒤에 나타납니다.
  -> http://www.joes-hardware.com/tools.html#drills
  

In this example, the fragment drills references a portion of the /tools.html web page located on the Joe’s Hardware web server. The portion is named “drills”.

• 예제에서 "drills" Frag는 Joe's Hardware 웹 서버에 위치한 /tools.html 웹페이지의 일부분을 참조합니다.

• 그 일부분의 이름이 "drills"입니다.

Because HTTP servers generally deal only with entire objects,* not with fragments of objects, clients don’t pass fragments along to servers (see Figure 2-3). After your browser gets the entire resource from the server, it then uses the fragment to display the part of the resource in which you are interested.

• HTTP 서버는 일반적으로 객체의 일부가 아닌 객체 전체를 다루기 때문에 클라이언트가 서버에 Fragment를 전달할 수 없습니다. (Figure 2-3)

• 브라우저는 서버로부터 전체 리소스를 가져온 후 필요한 리소스의 일부분을 화면에 표시하기 위해 Fragment를 사용합니다.

---

🧡 요약 정리 🧡

URL syntax

 <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

6. Paths

• 리소스가 존재하는 서버의 특정 위치
• "/" 문자를 통해 각각의 Path 세그먼트 구분
• Path 세그먼트에는 파라미터가 포함될 수 있다

7. Parameters

• 리소스에 접근하기 위해 요구되는 모든 추가 정보
• {name}={value} 형식으로 표현
• ";" 문자를 통해 다른 부분과 구분

8. Query Strings

• 게이트웨이 리소스에 전달되어 리소스의 유형을 한정하기 위한 정보
• 일반적으로 {name}={value} 형식으로 표현
• "?" 문자를 통해 앞의 URL과 구분

9. Fragments

• HTML과 같은 리소스의 일부분(이미지, 섹션 등)
• 브라우저가 Fragment의 이름을 통해 리소스의 일부분 참조
• URL의 마지막 부분에 "#" 문자를 통해 구분

---

💛 감상 💛

• 블로그를 이틀이나 안 썼다...! 야심차게 시작했지만 그새 또 마음이 꺾인 모양이다. 하지만 알고리즘 교수님께서 말씀하신 것처럼 비록 나태해지더라도 다시 심기일전해서 앞으로 나아가는 것이 중요한 게 아닐까. 오늘부터 다시 열심히 책을 읽어보겠다.

• Parameter와 Fragment 같은 구성 요소는 자세히 알지 못했던 부분이다. 이들이 구체적으로 어떤 의미를 가지는지 책을 읽으면서 이해할 수 있었다. 특히 Fragment가 서버단이 아닌 클라이언트단에서 사용되는 요소라는 디테일까지 배울 수 있었다. 하루에 고작 두 세 페이지 읽는 것이 전부지만, 그럼에도 그 안에 내가 알지 못했던 새롭고 재미있는 내용들이 꽤 많이 있는 것 같다.