rfc1738.txt

<VC++网络游戏建摸与实现>源代码

        The password is supplied as the Internet e-mail address
        of the end user accessing the resource.

   If the URL supplies a user name but no password, and the remote
   server requests a password, the program interpreting the FTP URL
   should request one from the user.

3.2.2. FTP url-path

   The url-path of a FTP URL has the following syntax:

        <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>

   Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
   and <typecode> is one of the characters "a", "i", or "d".  The part
   ";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
   empty. The whole url-path may be omitted, including the "/"
   delimiting it from the prefix containing user, password, host, and
   port.

   The url-path is interpreted as a series of FTP commands as follows:

      Each of the <cwd> elements is to be supplied, sequentially, as the
      argument to a CWD (change working directory) command.

      If the typecode is "d", perform a NLST (name list) command with
      <name> as the argument, and interpret the results as a file
      directory listing.

      Otherwise, perform a TYPE command with <typecode> as the argument,
      and then access the file whose name is <name> (for example, using
      the RETR command.)

   Within a name or CWD component, the characters "/" and ";" are
   reserved and must be encoded. The components are decoded prior to
   their use in the FTP protocol.  In particular, if the appropriate FTP
   sequence to access a particular file requires supplying a string
   containing a "/" as an argument to a CWD or RETR command, it is



Berners-Lee, Masinter & McCahill                                [Page 7]

RFC 1738            Uniform Resource Locators (URL)        December 1994


   necessary to encode each "/".

   For example, the URL <URL:ftp://[e-mail]/%2Fetc/motd> is
   interpreted by FTP-ing to "host.dom", logging in as "myname"
   (prompting for a password if it is asked for), and then executing
   "CWD /etc" and then "RETR motd". This has a different meaning from
   <URL:ftp://[e-mail]/etc/motd> which would "CWD etc" and then
   "RETR motd"; the initial "CWD" might be executed relative to the
   default directory for "myname". On the other hand,
   <URL:ftp://[e-mail]//etc/motd>, would "CWD " with a null
   argument, then "CWD etc", and then "RETR motd".

   FTP URLs may also be used for other operations; for example, it is
   possible to update a file on a remote file server, or infer
   information about it from the directory listings. The mechanism for
   doing so is not spelled out here.

3.2.3. FTP Typecode is Optional

   The entire ;type=<typecode> part of a FTP URL is optional. If it is
   omitted, the client program interpreting the URL must guess the
   appropriate mode to use. In general, the data content type of a file
   can only be guessed from the name, e.g., from the suffix of the name;
   the appropriate type code to be used for transfer of the file can
   then be deduced from the data content of the file.

3.2.4 Hierarchy

   For some file systems, the "/" used to denote the hierarchical
   structure of the URL corresponds to the delimiter used to construct a
   file name hierarchy, and thus, the filename will look similar to the
   URL path. This does NOT mean that the URL is a Unix filename.

3.2.5. Optimization

   Clients accessing resources via FTP may employ additional heuristics
   to optimize the interaction. For some FTP servers, for example, it
   may be reasonable to keep the control connection open while accessing
   multiple URLs from the same server. However, there is no common
   hierarchical model to the FTP protocol, so if a directory change
   command has been given, it is impossible in general to deduce what
   sequence should be given to navigate to another directory for a
   second retrieval, if the paths are different.  The only reliable
   algorithm is to disconnect and reestablish the control connection.







Berners-Lee, Masinter & McCahill                                [Page 8]

RFC 1738            Uniform Resource Locators (URL)        December 1994


3.3. HTTP

   The HTTP URL scheme is used to designate Internet resources
   accessible using HTTP (HyperText Transfer Protocol).

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the "/"
   may also be omitted.

   Within the <path> and <searchpart> components, "/", ";", "?" are
   reserved.  The "/" character may be used within HTTP to designate a
   hierarchical structure.

3.4. GOPHER

   The Gopher URL scheme is used to designate Internet resources
   accessible using the Gopher protocol.

   The base Gopher protocol is described in RFC 1436 and supports items
   and collections of items (directories). The Gopher+ protocol is a set
   of upward compatible extensions to the base Gopher protocol and is
   described in [2]. Gopher+ supports associating arbitrary sets of
   attributes and alternate data representations with Gopher items.
   Gopher URLs accommodate both Gopher and Gopher+ items and item
   attributes.

3.4.1. Gopher URL syntax

   A Gopher URL takes the form:

      gopher://<host>:<port>/<gopher-path>

   where <gopher-path> is one of

       <gophertype><selector>
       <gophertype><selector>%09<search>
       <gophertype><selector>%09<search>%09<gopher+_string>




Berners-Lee, Masinter & McCahill                                [Page 9]

RFC 1738            Uniform Resource Locators (URL)        December 1994


   If :<port> is omitted, the port defaults to 70.  <gophertype> is a
   single-character field to denote the Gopher type of the resource to
   which the URL refers. The entire <gopher-path> may also be empty, in
   which case the delimiting "/" is also optional and the <gophertype>
   defaults to "1".

   <selector> is the Gopher selector string.  In the Gopher protocol,
   Gopher selector strings are a sequence of octets which may contain
   any octets except 09 hexadecimal (US-ASCII HT or tab) 0A hexadecimal
   (US-ASCII character LF), and 0D (US-ASCII character CR).

   Gopher clients specify which item to retrieve by sending the Gopher
   selector string to a Gopher server.

   Within the <gopher-path>, no characters are reserved.

   Note that some Gopher <selector> strings begin with a copy of the
   <gophertype> character, in which case that character will occur twice
   consecutively. The Gopher selector string may be an empty string;
   this is how Gopher clients refer to the top-level directory on a
   Gopher server.

3.4.2 Specifying URLs for Gopher Search Engines

   If the URL refers to a search to be submitted to a Gopher search
   engine, the selector is followed by an encoded tab (%09) and the
   search string. To submit a search to a Gopher search engine, the
   Gopher client sends the <selector> string (after decoding), a tab,
   and the search string to the Gopher server.

3.4.3 URL syntax for Gopher+ items

   URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
   string. Note that in this case, the %09<search> string must be
   supplied, although the <search> element may be the empty string.

   The <gopher+_string> is used to represent information required for
   retrieval of the Gopher+ item. Gopher+ items may have alternate
   views, arbitrary sets of attributes, and may have electronic forms
   associated with them.

   To retrieve the data associated with a Gopher+ URL, a client will
   connect to the server and send the Gopher selector, followed by a tab
   and the search string (which may be empty), followed by a tab and the
   Gopher+ commands.






Berners-Lee, Masinter & McCahill                               [Page 10]

RFC 1738            Uniform Resource Locators (URL)        December 1994


3.4.4 Default Gopher+ data representation

   When a Gopher server returns a directory listing to a client, the
   Gopher+ items are tagged with either a "+" (denoting Gopher+ items)
   or a "?" (denoting Gopher+ items which have a +ASK form associated
   with them). A Gopher URL with a Gopher+ string consisting of only a
   "+" refers to the default view (data representation) of the item
   while a Gopher+ string containing only a "?" refer to an item with a
   Gopher electronic form associated with it.

3.4.5 Gopher+ items with electronic forms

   Gopher+ items which have a +ASK associated with them (i.e. Gopher+
   items tagged with a "?") require the client to fetch the item's +ASK
   attribute to get the form definition, and then ask the user to fill
   out the form and return the user's responses along with the selector
   string to retrieve the item.  Gopher+ clients know how to do this but
   depend on the "?" tag in the Gopher+ item description to know when to
   handle this case. The "?" is used in the Gopher+ string to be
   consistent with Gopher+ protocol's use of this symbol.

3.4.6 Gopher+ item attribute collections

   To refer to the Gopher+ attributes of an item, the Gopher URL's
   Gopher+ string consists of "!" or "$". "!" refers to the all of a
   Gopher+ item's attributes. "$" refers to all the item attributes for
   all items in a Gopher directory.

3.4.7 Referring to specific Gopher+ attributes

   To refer to specific attributes, the URL's gopher+_string is
   "!<attribute_name>" or "$<attribute_name>". For example, to refer to
   the attribute containing the abstract of an item, the gopher+_string
   would be "!+ABSTRACT".

   To refer to several attributes, the gopher+_string consists of the
   attribute names separated by coded spaces. For example,
   "!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes
   of an item.

3.4.8 URL syntax for Gopher+ alternate views

   Gopher+ allows for optional alternate data representations (alternate
   views) of items. To retrieve a Gopher+ alternate view, a Gopher+
   client sends the appropriate view and language identifier (found in
   the item's +VIEW attribute). To refer to a specific Gopher+ alternate
   view, the URL's Gopher+ string would be in the form:




Berners-Lee, Masinter & McCahill                               [Page 11]

RFC 1738            Uniform Resource Locators (URL)        December 1994


        +<view_name>%20<language_name>

   For example, a Gopher+ string of "+application/postscript%20Es_ES"
   refers to the Spanish language postscript alternate view of a Gopher+
   item.

3.4.9 URL syntax for Gopher+ electronic forms

   The gopher+_string for a URL that refers to an item referenced by a
   Gopher+ electronic form (an ASK block) filled out with specific
   values is a coded version of what the client sends to the server.
   The gopher+_string is of the form:

+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A

   To retrieve this item, the Gopher client sends:

       <a_gopher_selector><tab>+<tab>1<cr><lf>
       +-1<cr><lf>
       <ask_item1_value><cr><lf>
       <ask_item2_value><cr><lf>
       .<cr><lf>

   to the Gopher server.

3.5. MAILTO

   The mailto URL scheme is used to designate the Internet mailing
   address of an individual or service. No additional information other
   than an Internet mailing address is present or implied.

   A mailto URL takes the form:

        mailto:<rfc822-addr-spec>

   where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
   specified in RFC 822 [6]. Within mailto URLs, there are no reserved
   characters.

   Note that the percent sign ("%") is commonly used within RFC 822
   addresses and must be encoded.

   Unlike many URLs, the mailto scheme does not represent a data object
   to be accessed directly; there is no sense in which it designates an
   object. It has a different use than the message/external-body type in
   MIME.





Berners-Lee, Masinter & McCahill                               [Page 12]

RFC 1738            Uniform Resource Locators (URL)        December 1994


3.6. NEWS

   The news URL scheme is used to refer to either news groups or
   individual articles of USENET news, as specified in RFC 1036.

   A news URL takes one of two forms:

     news:<newsgroup-name>
     news:<message-id>

   A <newsgroup-name> is a period-delimited hierarchical name, such as
   "comp.infosystems.www.misc". A <message-id> corresponds to the
   Message-ID of section 2.1.5 of RFC 1036, without the enclosing "<"
   and ">"; it takes the form <unique>@<full_domain_name>.  A message
   identifier may be distinguished from a news group name by the
   presence of the commercial at "@" character. No additional characters
   are reserved within the components of a news URL.

   If <newsgroup-name> is "*" (as in <URL:news:*>), it is used to refer
   to "all available news groups".

   The news URLs are unusual in that by themselves, they do not contain
   sufficient information to locate a single resource, but, rather, are
   location-independent.