软件工程

本类阅读TOP10

·PHP4 + MYSQL + APACHE 在 WIN 系统下的安装、配置
·Linux 入门常用命令(1)
·Linux 入门常用命令(2)
·使用 DCPROMO/FORCEREMOVAL 命令强制将 Active Directory 域控制器降级
·DirectShow学习(八): CBaseRender类及相应Pin类的源代码分析
·基于ICE方式SIP信令穿透Symmetric NAT技术研究
·Windows 2003网络负载均衡的实现
·一网打尽Win十四种系统故障解决方法
·数百种 Windows 软件的免费替代品列表
·收藏---行百里半九十

分类导航
VC语言Delphi
VB语言ASP
PerlJava
Script数据库
其他语言游戏开发
文件格式网站制作
软件工程.NET开发
http1.1---10

作者:未知 来源:月光软件站 加入时间:2005-2-28 月光软件站

 

Fielding, et. al.           Standards Track                   [Page 131]

RFC 2068                        HTTP/1.1                    January 1997


14.39 Server

   The Server response-header field contains information about the
   software used by the origin server to handle the request. The field
   can contain multiple product tokens (section 3.8) and comments
   identifying the server and any significant subproducts. The product
   tokens are listed in order of their significance for identifying the
   application.

          Server         = "Server" ":" 1*( product | comment )

   Example:

          Server: CERN/3.0 libwww/2.17

   If the response is being forwarded through a proxy, the proxy
   application MUST NOT modify the Server response-header. Instead, it
   SHOULD include a Via field (as described in section 14.44).

     Note: Revealing the specific software version of the server may
     allow the server machine to become more vulnerable to attacks
     against software that is known to contain security holes. Server
     implementers are encouraged to make this field a configurable
     option.

14.40 Transfer-Encoding

   The Transfer-Encoding general-header field indicates what (if any)
   type of transformation has been applied to the message body in order
   to safely transfer it between the sender and the recipient. This
   differs from the Content-Encoding in that the transfer coding is a
   property of the message, not of the entity.

          Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-
   coding

   Transfer codings are defined in section 3.6. An example is:

          Transfer-Encoding: chunked

   Many older HTTP/1.0 applications do not understand the Transfer-
   Encoding header.

14.41 Upgrade

   The Upgrade general-header allows the client to specify what
   additional communication protocols it supports and would like to use
   if the server finds it appropriate to switch protocols. The server

 

Fielding, et. al.           Standards Track                   [Page 132]

RFC 2068                        HTTP/1.1                    January 1997


   MUST use the Upgrade header field within a 101 (Switching Protocols)
   response to indicate which protocol(s) are being switched.

          Upgrade        = "Upgrade" ":" 1#product

   For example,

          Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

   The Upgrade header field is intended to provide a simple mechanism
   for transition from HTTP/1.1 to some other, incompatible protocol. It
   does so by allowing the client to advertise its desire to use another
   protocol, such as a later version of HTTP with a higher major version
   number, even though the current request has been made using HTTP/1.1.
   This eases the difficult transition between incompatible protocols by
   allowing the client to initiate a request in the more commonly
   supported protocol while indicating to the server that it would like
   to use a "better" protocol if available (where "better" is determined
   by the server, possibly according to the nature of the method and/or
   resource being requested).

   The Upgrade header field only applies to switching application-layer
   protocols upon the existing transport-layer connection. Upgrade
   cannot be used to insist on a protocol change; its acceptance and use
   by the server is optional. The capabilities and nature of the
   application-layer communication after the protocol change is entirely
   dependent upon the new protocol chosen, although the first action
   after changing the protocol MUST be a response to the initial HTTP
   request containing the Upgrade header field.

   The Upgrade header field only applies to the immediate connection.
   Therefore, the upgrade keyword MUST be supplied within a Connection
   header field (section 14.10) whenever Upgrade is present in an
   HTTP/1.1 message.

   The Upgrade header field cannot be used to indicate a switch to a
   protocol on a different connection. For that purpose, it is more
   appropriate to use a 301, 302, 303, or 305 redirection response.

   This specification only defines the protocol name "HTTP" for use by
   the family of Hypertext Transfer Protocols, as defined by the HTTP
   version rules of section 3.1 and future updates to this
   specification. Any token can be used as a protocol name; however, it
   will only be useful if both the client and server associate the name
   with the same protocol.

 

 


Fielding, et. al.           Standards Track                   [Page 133]

RFC 2068                        HTTP/1.1                    January 1997


14.42 User-Agent

   The User-Agent request-header field contains information about the
   user agent originating the request. This is for statistical purposes,
   the tracing of protocol violations, and automated recognition of user
   agents for the sake of tailoring responses to avoid particular user
   agent limitations. User agents SHOULD include this field with
   requests. The field can contain multiple product tokens (section 3.8)
   and comments identifying the agent and any subproducts which form a
   significant part of the user agent. By convention, the product tokens
   are listed in order of their significance for identifying the
   application.

          User-Agent     = "User-Agent" ":" 1*( product | comment )

   Example:

          User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14.43 Vary

   The Vary response-header field is used by a server to signal that the
   response entity was selected from the available representations of
   the response using server-driven negotiation (section 12). Field-
   names listed in Vary headers are those of request-headers. The Vary
   field value indicates either that the given set of header fields
   encompass the dimensions over which the representation might vary, or
   that the dimensions of variance are unspecified ("*") and thus may
   vary over any aspect of future requests.

          Vary  = "Vary" ":" ( "*" | 1#field-name )

   An HTTP/1.1 server MUST include an appropriate Vary header field with
   any cachable response that is subject to server-driven negotiation.
   Doing so allows a cache to properly interpret future requests on that
   resource and informs the user agent about the presence of negotiation
   on that resource. A server SHOULD include an appropriate Vary header
   field with a non-cachable response that is subject to server-driven
   negotiation, since this might provide the user agent with useful
   information about the dimensions over which the response might vary.

   The set of header fields named by the Vary field value is known as
   the "selecting" request-headers.

   When the cache receives a subsequent request whose Request-URI
   specifies one or more cache entries including a Vary header, the
   cache MUST NOT use such a cache entry to construct a response to the
   new request unless all of the headers named in the cached Vary header

 

Fielding, et. al.           Standards Track                   [Page 134]

RFC 2068                        HTTP/1.1                    January 1997


   are present in the new request, and all of the stored selecting
   request-headers from the previous request match the corresponding
   headers in the new request.

   The selecting request-headers from two requests are defined to match
   if and only if the selecting request-headers in the first request can
   be transformed to the selecting request-headers in the second request
   by adding or removing linear whitespace (LWS) at places where this is
   allowed by the corresponding BNF, and/or combining multiple message-
   header fields with the same field name following the rules about
   message headers in section 4.2.

   A Vary field value of "*" signals that unspecified parameters,
   possibly other than the contents of request-header fields (e.g., the
   network address of the client), play a role in the selection of the
   response representation. Subsequent requests on that resource can
   only be properly interpreted by the origin server, and thus a cache
   MUST forward a (possibly conditional) request even when it has a
   fresh response cached for the resource. See section 13.6 for use of
   the Vary header by caches.

   A Vary field value consisting of a list of field-names signals that
   the representation selected for the response is based on a selection
   algorithm which considers ONLY the listed request-header field values
   in selecting the most appropriate representation. A cache MAY assume
   that the same selection will be made for future requests with the
   same values for the listed field names, for the duration of time in
   which the response is fresh.

   The field-names given are not limited to the set of standard
   request-header fields defined by this specification. Field names are
   case-insensitive.

14.44 Via

   The Via general-header field MUST be used by gateways and proxies to
   indicate the intermediate protocols and recipients between the user
   agent and the server on requests, and between the origin server and
   the client on responses. It is analogous to the "Received" field of
   RFC 822 and is intended to be used for tracking message forwards,
   avoiding request loops, and identifying the protocol capabilities of
   all senders along the request/response chain.

 

 

 

 

Fielding, et. al.           Standards Track                   [Page 135]

RFC 2068                        HTTP/1.1                    January 1997


      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )

      received-protocol = [ protocol-name "/" ] protocol-version
      protocol-name     = token
      protocol-version  = token
      received-by       = ( host [ ":" port ] ) | pseudonym
      pseudonym         = token

   The received-protocol indicates the protocol version of the message
   received by the server or client along each segment of the
   request/response chain. The received-protocol version is appended to
   the Via field value when the message is forwarded so that information
   about the protocol capabilities of upstream applications remains
   visible to all recipients.

   The protocol-name is optional if and only if it would be "HTTP". The
   received-by field is normally the host and optional port number of a
   recipient server or client that subsequently forwarded the message.
   However, if the real host is considered to be sensitive information,
   it MAY be replaced by a pseudonym. If the port is not given, it MAY
   be assumed to be the default port of the received-protocol.

   Multiple Via field values represent each proxy or gateway that has
   forwarded the message. Each recipient MUST append its information
   such that the end result is ordered according to the sequence of
   forwarding applications.

   Comments MAY be used in the Via header field to identify the software
   of the recipient proxy or gateway, analogous to the User-Agent and
   Server header fields. However, all comments in the Via field are
   optional and MAY be removed by any recipient prior to forwarding the
   message.

   For example, a request message could be sent from an HTTP/1.0 user
   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
   forward the request to a public proxy at nowhere.com, which completes
   the request by forwarding it to the origin server at www.ics.uci.edu.
   The request received by www.ics.uci.edu would then have the following
   Via header field:

          Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

   Proxies and gateways used as a portal through a network firewall
   SHOULD NOT, by default, forward the names and ports of hosts within
   the firewall region. This information SHOULD only be propagated if
   explicitly enabled. If not enabled, the received-by host of any host
   behind the firewall SHOULD be replaced by an appropriate pseudonym
   for that host.

 

Fielding, et. al.           Standards Track                   [Page 136]

RFC 2068                        HTTP/1.1                    January 1997


   For organizations that have strong privacy requirements for hiding
   internal structures, a proxy MAY combine an ordered subsequence of
   Via header field entries with identical received-protocol values into
   a single such entry. For example,

          Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

           could be collapsed to

          Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

   Applications SHOULD NOT combine multiple entries unless they are all
   under the same organizational control and the hosts have already been
   replaced by pseudonyms. Applications MUST NOT combine entries which
   have different received-protocol values.

14.45 Warning

   The Warning response-header field is used to carry additional
   information about the status of a response which may not be reflected
   by the response status code. This information is typically, though
   not exclusively, used to warn about a possible lack of semantic
   transparency from caching operations.

   Warning headers are sent with responses using:

          Warning    = "Warning" ":" 1#warning-value

          warning-value = warn-code SP warn-agent SP warn-text
          warn-code  = 2DIGIT
          warn-agent = ( host [ ":" port ] ) | pseudonym
                          ; the name or pseudonym of the server adding
                          ; the Warning header, for use in debugging
          warn-text  = quoted-string

   A response may carry more than one Warning header.

   The warn-text should be in a natural language and character set that
   is most likely to be intelligible to the human user receiving the
   response.  This decision may be based on any available knowledge,
   such as the location of the cache or user, the Accept-Language field
   in a request, the Content-Language field in a response, etc. The
   default language is English and the default character set is ISO-
   8859-1.

   If a character set other than ISO-8859-1 is used, it MUST be encoded
   in the warn-text using the method described in RFC 1522 [14].

 


Fielding, et. al.           Standards Track                   [Page 137]

RFC 2068                        HTTP/1.1                    January 1997


   Any server or cache may add Warning headers to a response. New
   Warning headers should be added after any existing Warning headers. A
   cache MUST NOT delete any Warning header that it received with a
   response. However, if a cache successfully validates a cache entry,
   it SHOULD remove any Warning headers previously attached to that
   entry except as specified for specific Warning codes. It MUST then
   add any Warning headers received in the validating response. In other
   words, Warning headers are those that would be attached to the most
   recent relevant response.

   When multiple Warning headers are attached to a response, the user
   agent SHOULD display as many of them as possible, in the order that
   they appear in the response. If it is not possible to display all of
   the warnings, the user agent should follow these heuristics:

     o  Warnings that appear early in the response take priority over those
        appearing later in the response.
     o  Warnings in the user's preferred character set take priority over
        warnings in other character sets but with identical warn-codes and
        warn-agents.

   Systems that generate multiple Warning headers should order them with
   this user agent behavior in mind.

   This is a list of the currently-defined warn-codes, each with a
   recommended warn-text in English, and a description of its meaning.

10 Response is stale
  MUST be included whenever the returned response is stale. A cache may
  add this warning to any response, but may never remove it until the
  response is known to be fresh.

11 Revalidation failed
  MUST be included if a cache returns a stale response because an
  attempt to revalidate the response failed, due to an inability to
  reach the server. A cache may add this warning to any response, but
  may never remove it until the response is successfully revalidated.

12 Disconnected operation
   SHOULD be included if the cache is intentionally disconnected from
  the rest of the network for a period of time.

13 Heuristic expiration
  MUST be included if the cache heuristically chose a freshness
  lifetime greater than 24 hours and the response's age is greater than
  24 hours.

 

 

Fielding, et. al.           Standards Track                   [Page 138]

RFC 2068                        HTTP/1.1                    January 1997


14 Transformation applied
  MUST be added by an intermediate cache or proxy if it applies any
  transformation changing the content-coding (as specified in the
  Content-Encoding header) or media-type (as specified in the
  Content-Type header) of the response, unless this Warning code
  already appears in the response. MUST NOT be deleted from a response
  even after revalidation.

99 Miscellaneous warning
  The warning text may include arbitrary information to be presented to
  a human user, or logged. A system receiving this warning MUST NOT
  take any automated action.

14.46 WWW-Authenticate

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages. The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the Request-URI.

          WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

   The HTTP access authentication process is described in section 11.
   User agents MUST take special care in parsing the WWW-Authenticate
   field value if it contains more than one challenge, or if more than
   one WWW-Authenticate header field is provided, since the contents of
   a challenge may itself contain a comma-separated list of
   authentication parameters.

15 Security Considerations

   This section is meant to inform application developers, information
   providers, and users of the security limitations in HTTP/1.1 as
   described by this document. The discussion does not include
   definitive solutions to the problems revealed, though it does make
   some suggestions for reducing security risks.

15.1 Authentication of Clients

   The Basic authentication scheme is not a secure method of user
   authentication, nor does it in any way protect the entity, which is
   transmitted in clear text across the physical network used as the
   carrier. HTTP does not prevent additional authentication schemes and
   encryption mechanisms from being employed to increase security or the
   addition of enhancements (such as schemes to use one-time passwords)
   to Basic authentication.

 

 

Fielding, et. al.           Standards Track                   [Page 139]

RFC 2068                        HTTP/1.1                    January 1997


   The most serious flaw in Basic authentication is that it results in
   the essentially clear text transmission of the user's password over
   the physical network. It is this problem which Digest Authentication
   attempts to address.

   Because Basic authentication involves the clear text transmission of
   passwords it SHOULD never be used (without enhancements) to protect
   sensitive or valuable information.

   A common use of Basic authentication is for identification purposes
   -- requiring the user to provide a user name and password as a means
   of identification, for example, for purposes of gathering accurate
   usage statistics on a server. When used in this way it is tempting to
   think that there is no danger in its use if illicit access to the
   protected documents is not a major concern. This is only correct if
   the server issues both user name and password to the users and in
   particular does not allow the user to choose his or her own password.
   The danger arises because naive users frequently reuse a single
   password to avoid the task of maintaining multiple passwords.

   If a server permits users to select their own passwords, then the
   threat is not only illicit access to documents on the server but also
   illicit access to the accounts of all users who have chosen to use
   their account password. If users are allowed to choose their own
   password that also means the server must maintain files containing
   the (presumably encrypted) passwords. Many of these may be the
   account passwords of users perhaps at distant sites. The owner or
   administrator of such a system could conceivably incur liability if
   this information is not maintained in a secure fashion.

   Basic Authentication is also vulnerable to spoofing by counterfeit
   servers. If a user can be led to believe that he is connecting to a
   host containing information protected by basic authentication when in
   fact he is connecting to a hostile server or gateway then the
   attacker can request a password, store it for later use, and feign an
   error. This type of attack is not possible with Digest Authentication
   [32]. Server implementers SHOULD guard against the possibility of
   this sort of counterfeiting by gateways or CGI scripts. In particular
   it is very dangerous for a server to simply turn over a connection to
   a gateway since that gateway can then use the persistent connection
   mechanism to engage in multiple transactions with the client while
   impersonating the original server in a way that is not detectable by
   the client.

15.2 Offering a Choice of Authentication Schemes

   An HTTP/1.1 server may return multiple challenges with a 401
   (Authenticate) response, and each challenge may use a different

 

Fielding, et. al.           Standards Track                   [Page 140]

RFC 2068                        HTTP/1.1                    January 1997


   scheme.  The order of the challenges returned to the user agent is in
   the order that the server would prefer they be chosen. The server
   should order its challenges with the "most secure" authentication
   scheme first. A user agent should choose as the challenge to be made
   to the user the first one that the user agent understands.

   When the server offers choices of authentication schemes using the
   WWW-Authenticate header, the "security" of the authentication is only
   as malicious user could capture the set of challenges and try to
   authenticate him/herself using the weakest of the authentication
   schemes. Thus, the ordering serves more to protect the user's
   credentials than the server's information.

   A possible man-in-the-middle (MITM) attack would be to add a weak
   authentication scheme to the set of choices, hoping that the client
   will use one that exposes the user's credentials (e.g. password). For
   this reason, the client should always use the strongest scheme that
   it understands from the choices accepted.

   An even better MITM attack would be to remove all offered choices,
   and to insert a challenge that requests Basic authentication. For
   this reason, user agents that are concerned about this kind of attack
   could remember the strongest authentication scheme ever requested by
   a server and produce a warning message that requires user
   confirmation before using a weaker one. A particularly insidious way
   to mount such a MITM attack would be to offer a "free" proxy caching
   service to gullible users.

15.3 Abuse of Server Log Information

   A server is in the position to save personal data about a user's
   requests which may identify their reading patterns or subjects of
   interest. This information is clearly confidential in nature and its
   handling may be constrained by law in certain countries. People using
   the HTTP protocol to provide data are responsible for ensuring that
   such material is not distributed without the permission of any
   individuals that are identifiable by the published results.

15.4 Transfer of Sensitive Information

   Like any generic data transfer protocol, HTTP cannot regulate the
   content of the data that is transferred, nor is there any a priori
   method of determining the sensitivity of any particular piece of
   information within the context of any given request. Therefore,
   applications SHOULD supply as much control over this information as
   possible to the provider of that information. Four header fields are
   worth special mention in this context: Server, Via, Referer and From.

 


Fielding, et. al.           Standards Track                   [Page 141]

RFC 2068                        HTTP/1.1                    January 1997


   Revealing the specific software version of the server may allow the
   server machine to become more vulnerable to attacks against software
   that is known to contain security holes. Implementers SHOULD make the
   Server header field a configurable option.

   Proxies which serve as a portal through a network firewall SHOULD
   take special precautions regarding the transfer of header information
   that identifies the hosts behind the firewall. In particular, they
   SHOULD remove, or replace with sanitized versions, any Via fields
   generated behind the firewall.

   The Referer field allows reading patterns to be studied and reverse
   links drawn. Although it can be very useful, its power can be abused
   if user details are not separated from the information contained in
   the Referer. Even when the personal information has been removed, the
   Referer field may indicate a private document's URI whose publication
   would be inappropriate.

   The information sent in the From field might conflict with the user's
   privacy interests or their site's security policy, and hence it
   SHOULD NOT be transmitted without the user being able to disable,
   enable, and modify the contents of the field. The user MUST be able
   to set the contents of this field within a user preference or
   application defaults configuration.

   We suggest, though do not require, that a convenient toggle interface
   be provided for the user to enable or disable the sending of From and
   Referer information.

15.5 Attacks Based On File and Path Names

   Implementations of HTTP origin servers SHOULD be careful to restrict
   the documents returned by HTTP requests to be only those that were
   intended by the server administrators. If an HTTP server translates
   HTTP URIs directly into file system calls, the server MUST take
   special care not to serve files that were not intended to be
   delivered to HTTP clients.  For example, UNIX, Microsoft Windows, and
   other operating systems use ".." as a path component to indicate a
   directory level above the current one. On such a system, an HTTP
   server MUST disallow any such construct in the Request-URI if it
   would otherwise allow access to a resource outside those intended to
   be accessible via the HTTP server. Similarly, files intended for
   reference only internally to the server (such as access control
   files, configuration files, and script code) MUST be protected from
   inappropriate retrieval, since they might contain sensitive
   information. Experience has shown that minor bugs in such HTTP server
   implementations have turned into security risks.

 


Fielding, et. al.           Standards Track                   [Page 142]

RFC 2068                        HTTP/1.1                    January 1997


15.6 Personal Information

   HTTP clients are often privy to large amounts of personal information
   (e.g. the user's name, location, mail address, passwords, encryption
   keys, etc.), and SHOULD be very careful to prevent unintentional
   leakage of this information via the HTTP protocol to other sources.
   We very strongly recommend that a convenient interface be provided
   for the user to control dissemination of such information, and that
   designers and implementers be particularly careful in this area.
   History shows that errors in this area are often both serious
   security and/or privacy problems, and often generate highly adverse
   publicity for the implementer's company.

15.7 Privacy Issues Connected to Accept Headers

   Accept request-headers can reveal information about the user to all
   servers which are accessed. The Accept-Language header in particular
   can reveal information the user would consider to be of a private
   nature, because the understanding of particular languages is often
   strongly correlated to the membership of a particular ethnic group.
   User agents which offer the option to configure the contents of an
   Accept-Language header to be sent in every request are strongly
   encouraged to let the configuration process include a message which
   makes the user aware of the loss of privacy involved.

   An approach that limits the loss of privacy would be for a user agent
   to omit the sending of Accept-Language headers by default, and to ask
   the user whether it should start sending Accept-Language headers to a
   server if it detects, by looking for any Vary response-header fields
   generated by the server, that such sending could improve the quality
   of service.

   Elaborate user-customized accept header fields sent in every request,
   in particular if these include quality values, can be used by servers
   as relatively reliable and long-lived user identifiers. Such user
   identifiers would allow content providers to do click-trail tracking,
   and would allow collaborating content providers to match cross-server
   click-trails or form submissions of individual users. Note that for
   many users not behind a proxy, the network address of the host
   running the user agent will also serve as a long-lived user
   identifier. In environments where proxies are used to enhance
   privacy, user agents should be conservative in offering accept header
   configuration options to end users. As an extreme privacy measure,
   proxies could filter the accept headers in relayed requests. General
   purpose user agents which provide a high degree of header
   configurability should warn users about the loss of privacy which can
   be involved.

 


Fielding, et. al.           Standards Track                   [Page 143]

RFC 2068                        HTTP/1.1                    January 1997


15.8 DNS Spoofing

   Clients using HTTP rely heavily on the Domain Name Service, and are
   thus generally prone to security attacks based on the deliberate
   mis-association of IP addresses and DNS names. Clients need to be
   cautious in assuming the continuing validity of an IP number/DNS name
   association.

   In particular, HTTP clients SHOULD rely on their name resolver for
   confirmation of an IP number/DNS name association, rather than
   caching the result of previous host name lookups. Many platforms
   already can cache host name lookups locally when appropriate, and
   they SHOULD be configured to do so. These lookups should be cached,
   however, only when the TTL (Time To Live) information reported by the
   name server makes it likely that the cached information will remain
   useful.

   If HTTP clients cache the results of host name lookups in order to
   achieve a performance improvement, they MUST observe the TTL
   information reported by DNS.

   If HTTP clients do not observe this rule, they could be spoofed when
   a previously-accessed server's IP address changes. As network
   renumbering is expected to become increasingly common, the
   possibility of this form of attack will grow. Observing this
   requirement thus reduces this potential security vulnerability.

   This requirement also improves the load-balancing behavior of clients
   for replicated servers using the same DNS name and reduces the
   likelihood of a user's experiencing failure in accessing sites which
   use that strategy.

15.9 Location Headers and Spoofing

   If a single server supports multiple organizations that do not trust
   one another, then it must check the values of Location and Content-
   Location headers in responses that are generated under control of
   said organizations to make sure that they do not attempt to
   invalidate resources over which they have no authority.

16 Acknowledgments

   This specification makes heavy use of the augmented BNF and generic
   constructs defined by David H. Crocker for RFC 822. Similarly, it
   reuses many of the definitions provided by Nathaniel Borenstein and
   Ned Freed for MIME. We hope that their inclusion in this
   specification will help reduce past confusion over the relationship
   between HTTP and Internet mail message formats.

 

Fielding, et. al.           Standards Track                   [Page 144]

RFC 2068                        HTTP/1.1                    January 1997


   The HTTP protocol has evolved considerably over the past four years.
   It has benefited from a large and active developer community--the
   many people who have participated on the www-talk mailing list--and
   it is that community which has been most responsible for the success
   of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
   VanHeyningen deserve special recognition for their efforts in
   defining early aspects of the protocol.

   This document has benefited greatly from the comments of all those
   participating in the HTTP-WG. In addition to those already mentioned,
   the following individuals have contributed to this specification:

          Gary Adams                  Albert Lunde
          Harald Tveit Alvestrand     John C. Mallery
          Keith Ball                  Jean-Philippe Martin-Flatin
          Brian Behlendorf            Larry Masinter
          Paul Burchard               Mitra
          Maurizio Codogno            David Morris
          Mike Cowlishaw              Gavin Nicol
          Roman Czyborra              Bill Perry
          Michael A. Dolan            Jeffrey Perry
          David J. Fiander            Scott Powers
          Alan Freier                 Owen Rees
          Marc Hedlund                Luigi Rizzo
          Greg Herlihy                David Robinson
          Koen Holtman                Marc Salomon
          Alex Hopmann                Rich Salz
          Bob Jernigan                Allan M. Schiffman
          Shel Kaphan                 Jim Seidman
          Rohit Khare                 Chuck Shotton
          John Klensin                Eric W. Sink
          Martijn Koster              Simon E. Spero
          Alexei Kosut                Richard N. Taylor
          David M. Kristol            Robert S. Thau
          Daniel LaLiberte            Bill (BearHeart) Weinman
          Ben Laurie                  Francois Yergeau
          Paul J. Leach               Mary Ellen Zurko
          Daniel DuBois

   Much of the content and presentation of the caching design is due to
   suggestions and comments from individuals including: Shel Kaphan,
   Paul Leach, Koen Holtman, David Morris, and Larry Masinter.

 

谁翻译了别忘了给我发一份 [email protected]

 




相关文章

相关软件