rfc3205.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/3 页

   and the overloading of port numbers erodes this utility.  Attempting
   to circumvent a site's security policy is not an acceptable
   justification for doing so.

   It would be useful to establish guidelines for "firewall-friendly"
   protocols, to make it easier for existing firewalls to be compatible
   with new protocols.

2.5 Questions to be asked when considering use of HTTP

   o  When considering payload size and traffic patterns, is HTTP an
      appropriate transport for the anticipated use of this protocol?






Moore                    Best Current Practice                  [Page 5]

RFC 3205                     HTTP Layering                 February 2002


      (In other words: will the payload size be worth the overhead
      associated with TCP and HTTP?  Or will the application be able to
      make use of HTTP persistent connections to amortize the cost of
      that overhead over several requests?)

   o  Is this new protocol usable by existing web browsers without
      modification?

      (For example: Is the request transmitted as if it were a filled-in
      HTML form?  Is the response which is returned viewable from a web
      browser, say as HTML?)

   o  Are the existing HTTP security mechanisms appropriate for the new
      application?

   o  Are HTTP status codes and the HTTP status code paradigm suitable
      for this application?  (see section 8)

   o  Does the server for this application need to support HTTP anyway?

3. Issues Regarding Reuse of Port 80

   IANA has reserved TCP port number 80 for use by HTTP.  It would not
   be appropriate for a substantially new service, even one which uses
   HTTP as a substrate, to usurp port 80 from its traditional use.  A
   new use of HTTP might be considered a "substantially new service",
   thus requiring a new port, if any of the following are true:

   o  The "new service" and traditional HTTP service are likely to
      reference different sets of data, even when they both operate on
      the same host.

   o  There is a good reason for the "new service" to be implemented by
      a separate server process, or separate code, than traditional HTTP
      service on the same host, at least on some platforms.

   o  There is a good reason to want to easily distinguish the traffic
      of the "new service" from traditional HTTP, e.g., for the purposes
      of firewall access control or traffic analysis.

   o  If none of the above are true, it is arguable that the new use of
      HTTP is an "extension" to traditional HTTP, rather than a "new
      service".  Extensions to HTTP which share data with traditional
      HTTP services should probably define new HTTP methods to describe
      those extensions, rather than using separate ports.  If separate
      ports are used, there is no way for a client to know whether they
      are separate services or different ways of accessing the same
      underlying service.



Moore                    Best Current Practice                  [Page 6]

RFC 3205                     HTTP Layering                 February 2002


4. Issues Regarding Reuse of the http: Scheme in URLs

   A number of different URL schemes are in widespread use and many more
   are in the process of being standardized.  In practice, the URL
   scheme not only serves as a "tag" to govern the interpretation of the
   remaining portion of the URL, it also provides coarse identification
   of the kind of resource or service which is being accessed.  For
   example, web browsers typically provide a different response when a
   user mouse-clicks on an "http" URL, than when the user clicks on a
   "mailto" URL.

   Some criteria that might be used in making this determination are:

   o  Whether this URL scheme is likely to become widely used, versus
      used only in limited communities or by private agreement.

   o  Whether a new "default port" is needed.  If reuse of port 80 is
      not appropriate (see above), a new "default port" is needed.  A
      new default port in turn requires that a new URL scheme be
      registered if that URL scheme is expected to be widely used.
      Explicit port numbers in URLs are regarded as an "escape hatch",
      not something for use in ordinary circumstances.

   o  Whether use of the new service is likely to require a
      substantially different setup or protocol interaction with the
      server, than ordinary HTTP service.  This could include the need
      to request a different type of service from the network, or to
      reserve bandwidth, or to present different TLS authentication
      credentials to the server, or different kind of server
      provisioning, or any number of other needs.

   o  Whether user interfaces (such as web browsers) are likely to be
      able to exploit the difference in the URL prefix to produce a
      significant improvement in usability.

   According to the rules in [8] the "http:" URI is part of the "IETF
   Tree" for URL scheme names, and IETF is the maintainer of the "IETF
   Tree".  Since IESG is the decision-making body for IETF, IESG has the
   authority to determine whether a resource accessed by a protocol that
   is layered on top of HTTP, should use http: or some other URL prefix.

   Note that the convention of appending an "s" to the URL scheme to
   mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and
   of limited value.  For most applications, a single "use TLS or SSL"
   bit is not sufficient to adequately convey the information that a
   client needs to authenticate itself to a server, even if it has the
   proper credentials.  For instance, in order to ensure that adequate
   security is provided with TLS an application may need to be



Moore                    Best Current Practice                  [Page 7]

RFC 3205                     HTTP Layering                 February 2002


   configured with a list of acceptable ciphersuites, or with the client
   certificate to be used to authenticate to a particular server.  When
   it is necessary to specify authentication or other connection setup
   information in a URL these should be communicated in URL parameters,
   rather than in the URL prefix.

5. Issues regarding use of MIME media types

   Since HTTP uses the MIME media type system [9] to label its payload,
   many applications which layer on HTTP will need to define, or select,
   MIME media types for use by that application.  Especially when using
   a multipart structure, the choice of media types requires careful
   consideration.  In particular:

   o  Should some existing framework be used, such as text/directory
      [10], or XML [11,12], or should the new content-types be built
      from scratch?  Just as with HTTP, it's useful if code can be
      reused, but protocol designers should not be over-eager to
      incorporate a general but complex framework into a new protocol.
      Experience with ASN.1, for example, suggests that the advantage of
      using a general framework may not be worth the cost.

   o  Should MIME multipart or message types be allowed?  This can be an
      advantage if it is desirable to incorporate (for example) the
      multipart/alternative construct or the MIME security framework.
      On the other hand, these constructs were designed specifically for
      use in store-and-forward electronic mail systems, and other
      mechanisms may be more appropriate for the application being
      considered.

      The point here is that a decision to use MIME content-type names
      to describe protocol payloads (which is generally desirable if the
      same payloads may appear in other applications) does not imply
      that the application must accept arbitrary MIME content-types,
      including MIME multipart or security mechanisms.  Nor does it
      imply that the application must use MIME syntax or that it must
      recognize or even tolerate existing MIME header fields.

   o  If the same payload is likely to be sent over electronic mail, the
      differences between HTTP encoding of the payload and email
      encoding of the payload should be minimized.  Ideally, there
      should be no differences in the "canonical form" used in the two
      environments.  Text/* media types can be problematic in this
      regard because MIME email requires CRLF for line endings of text/*
      body parts, where HTTP traditionally uses LF only.






Moore                    Best Current Practice                  [Page 8]

RFC 3205                     HTTP Layering                 February 2002


   o  A MIME content-type label describes the nature of the object being
      labeled.  It does not describe, and should not be used to
      describe, the semantics which should be applied when the object is
      received.  For instance, the transmission of an object with a
      particular content-type using HTTP POST, should not be taken as a
      request for some operation based solely on the type.  The request
      should be separate from the content-type label and it should be
      explicit.

      When it is necessary for a protocol layered on HTTP to allow
      different operations on the same type of object, this can be
      communicated in a number of different ways: HTTP methods, HTTP
      request-URI, HTTP request headers, the MIME Content-Disposition
      header field, or as part of the payload.

6. Issues Regarding Existing vs.  New HTTP Methods

   It has been suggested that a new service layered on top of HTTP
   should define one or more new HTTP methods, rather than allocating a
   new port.  The use of new methods may be appropriate, but is not
   sufficient in all cases.  The definition of one or more new methods
   for use in a new protocol, does not by itself alleviate the need for
   use of a new port, or a new URL type.

7. Issues regarding reuse of HTTP client, server, and proxy code

   As mentioned earlier, one of the primary reasons for the use of HTTP
   as a substrate for new protocols, is to allow reuse of existing HTTP
   client, server, or proxy code.  However, HTTP was not designed for
   such layering.  Existing HTTP client and code may have "http"
   assumptions wired into them.  For instance, client libraries and
   proxies may expect "http:" URLs, and clients and servers may send
   (and expect) "HTTP/1.1", in requests and responses, as opposed to the
   name of the layered protocol and its version number.

   Existing client libraries may not understand new URL types.  In order
   to get a new HTTP-layered application client to work with an existing
   client library, it may be necessary for the application to convert
   its URLs to an "http equivalent" form.  For instance, if service
   "xyz" is layered on top of HTTP using port ###, the xyz client may
   need, when invoking an HTTP client library, to translate its URLs
   from "xyz://host/something" format to "http://host:###/something" for
   the purpose of calling that library.  This should be done ONLY when
   calling the HTTP client library - such URLs should not be used in
   other parts of the protocol, nor should they be exposed to users.






Moore                    Best Current Practice                  [Page 9]

RFC 3205                     HTTP Layering                 February 2002


   Note that when a client is sending requests directly to an origin
   server, the URL prefix ("http:") is not normally sent.  So
   translating xyz: URLs to http: URLs when calling the client library
   should not actually cause http: URLs to be sent over the wire.  But
   when the same client is sending requests to a proxy server, the
   client will normally send the entire URL (including the http: prefix)
   in those requests.  The proxy will remove the http: prefix when the
   request is communicated to the origin server.

   Existing HTTP client libraries and servers will transmit "HTTP/1.1"
   (or a different version) in requests and responses.  To facilitate
   reuse of such libraries and servers by a new protocol, such a
   protocol may therefore need to transmit and accept "HTTP/1.1" rather
   than its own protocol name and version number.  Designers of
   protocols which are layered on top of HTTP should explicitly choose
   whether or not to accept "HTTP/1.1" in protocol exchanges.