第23页 Chapter 2. URLs and Resources

* Chapter 2. URLs and Resources
** Navigating the Internet’s Resources
   - URL: scheme://host/path
     - scheme: how
     - host: where
     - path: whwat


** URL Syntax
   - Most URL schemes base their URL syntax on this nine-part general format:
#+begin_example
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
#+end_example

   - General URL componenets
     - scheme
     - user
     - password
     - host
     - port
     - path
     - params: Used by some schemes to specify input parameters. Params are name/value pairs. A URL can contain multiple params fields, separated from themselves and the rest of the path by semicolons (;).
     - query: Used by some schemes to pass parameters to active applications (such as databases, bulletin boards, search engines, and other Internet gateways). There is no common format for the contents of the query component. It is separated from the rest of the URL by the “?” character.
     - frag: A name for a piece or part of the resource. The frag field is not passed to the server when referencing the object; it is used internally by the client. It is separated from the rest of the URL by the “#” character.


*** 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.
    - 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.
    - 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.
    - 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. 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.


*** Query Strings
    - Basically, gateways can be thought of as access points to other applications.
    - 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.


*** Fragments
    - 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.
    - 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.


** URL shortcuts

*** Relative URLs
    - Relative URLs provide a convenient way to keep a set of resources (such as HTML pages) portable.


** Shady Characters

*** Encoding Mechanisms
    - Some encoded character examples
      - ~ 126(0x7e)
      - SPACE 32(0x20)
      - % 37(0x25)


** A Sea of Schemes
   - Common scheme formats
     - http
     - https
     - mailto
     - ftp
     - rtsp,rtspu
     - file
     - news
     - telnet


** The Future
   - However, they are not perfect. URLs are really addresses, not true names. This means that a URL tells you where something is located, for the moment. It provides you with the name of a specific server on a specific port, where you can find the resource. The downfall of this scheme is that if the resource is moved, the URL is no longer valid. And at that point, it provides no way to locate the object.
   - What would be ideal is if you had the real name of an object, which you could use to look up that object regardless of its location. As with a person, given the name of the resource and a few other facts, you could track down that resource, regardless of where it moved.