rfc3143.txt

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

Network Working Group                                          I. Cooper
Request for Comments: 3143                                 Equinix, Inc.
Category: Informational                                        J. Dilley
                                               Akamai Technologies, Inc.
                                                               June 2001


                   Known HTTP Proxy/Caching Problems

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document catalogs a number of known problems with World Wide Web
   (WWW) (caching) proxies and cache servers.  The goal of the document
   is to provide a discussion of the problems and proposed workarounds,
   and ultimately to improve conditions by illustrating problems.  The
   construction of this document is a joint effort of the Web caching
   community.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1   Problem Template . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Known Problems . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1   Known Specification Problems . . . . . . . . . . . . . . . .  5
   2.1.1 Vary header is underspecified and/or misleading  . . . . . .  5
   2.1.2 Client Chaining Loses Valuable Length Meta-Data  . . . . . .  9
   2.2   Known Architectural Problems . . . . . . . . . . . . . . . . 10
   2.2.1 Interception proxies break client cache directives . . . . . 10
   2.2.2 Interception proxies prevent introduction of new HTTP
            methods  . . . . . . . . . . . . . . . . . . . . . . . .  11
   2.2.3 Interception proxies break IP address-based authentication . 12
   2.2.4 Caching proxy peer selection in heterogeneous networks . . . 13
   2.2.5 ICP Performance  . . . . . . . . . . . . . . . . . . . . . . 15
   2.2.6 Caching proxy meshes can break HTTP serialization of content 16
   2.3   Known Implementation Problems  . . . . . . . . . . . . . . . 17
   2.3.1 User agent/proxy failover  . . . . . . . . . . . . . . . . . 17
   2.3.2 Some servers send bad Content-Length headers for files that
            contain CR . . . . . . . . . . . . . . . . . . . . . . .  18



Cooper & Dilley              Informational                      [Page 1]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 18
         References . . . . . . . . . . . . . . . . . . . . . . . . . 19
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
   A.    Archived Known Problems  . . . . . . . . . . . . . . . . . . 21
   A.1   Architectural  . . . . . . . . . . . . . . . . . . . . . . . 21
   A.1.1 Cannot specify multiple URIs for replicated resources  . . . 21
   A.1.2 Replica distance is unknown  . . . . . . . . . . . . . . . . 22
   A.1.3 Proxy resource location  . . . . . . . . . . . . . . . . . . 23
   A.2   Implementation . . . . . . . . . . . . . . . . . . . . . . . 23
   A.2.1 Use of Cache-Control headers . . . . . . . . . . . . . . . . 23
   A.2.2 Lack of HTTP/1.1 compliance for caching proxies  . . . . . . 24
   A.2.3 ETag support . . . . . . . . . . . . . . . . . . . . . . . . 25
   A.2.4 Servers and content should be optimized for caching  . . . . 26
   A.3   Administration . . . . . . . . . . . . . . . . . . . . . . . 27
   A.3.1 Lack of fine-grained, standardized hierarchy controls  . . . 27
   A.3.2 Proxy/Server exhaustive log format standard for analysis . . 27
   A.3.3 Trace log timestamps . . . . . . . . . . . . . . . . . . . . 28
   A.3.4 Exchange format for log summaries  . . . . . . . . . . . . . 29
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 32

1. Introduction

   This memo discusses problems with proxies - which act as
   application-level intermediaries for Web requests - and more
   specifically with caching proxies, which retain copies of previously
   requested resources in the hope of improving overall quality of
   service by serving the content locally.  Commonly used terminology in
   this memo can be found in the "Internet Web Replication and Caching
   Taxonomy"[2].

   No individual or organization has complete knowledge of the known
   problems in Web caching, and the editors are grateful to the
   contributors to this document.

1.1 Problem Template

   A common problem template is used within the following sections.  We
   gratefully acknowledge RFC2525 [1] which helped define an initial
   format for this known problems list.  The template format is
   summarized in the following table and described in more detail below.

      Name:           short, descriptive name of the problem (3-5 words)
      Classification: classifies the problem: performance, security, etc
      Description:    describes the problem succinctly
      Significance:   magnitude of problem, environments where it exists
      Implications:   the impact of the problem on systems and networks
      See Also:       a reference to a related known problem
      Indications:    states how to detect the presence of this problem



Cooper & Dilley              Informational                      [Page 2]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


      Solution(s):    describe the solution(s) to this problem, if any
      Workaround:     practical workaround for the problem
      References:     information about the problem or solution
      Contact:        contact name and email address for this section

   Name
      A short, descriptive, name (3-5 words) name associated with the
      problem.

   Classification
      Problems are grouped into categories of similar problems for ease
      of reading of this memo.  Choose the category that best describes
      the problem.  The suggested categories include three general
      categories and several more specific categories.

      *  Architecture: the fundamental design is incomplete, or
         incorrect

      *  Specification: the spec is ambiguous, incomplete, or incorrect.

      *  Implementation: the implementation of the spec is incorrect.

      *  Performance: perceived page response at the client is
         excessive; network bandwidth consumption is excessive; demand
         on origin or proxy servers exceed reasonable bounds.

      *  Administration: care and feeding of caches is, or causes, a
         problem.

      *  Security: privacy, integrity, or authentication concerns.

   Description
      A definition of the problem, succinct but including necessary
      background information.

   Significance (High, Medium, Low)
      May include a brief summary of the environments for which the
      problem is significant.

   Implications
      Why the problem is viewed as a problem.  What inappropriate
      behavior results from it? This section should substantiate the
      magnitude of any problem indicated with High significance.

   See Also
      Optional.  List of other known problems that are related to this
      one.




Cooper & Dilley              Informational                      [Page 3]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


   Indications
      How to detect the presence of the problem.  This may include
      references to one or more substantiating documents that
      demonstrate the problem.  This should include the network
      configuration that led to the problem such that it can be
      reproduced.  Problems that are not reproducible will not appear in
      this memo.

   Solution(s)
      Solutions that permanently fix the problem, if such are known. For
      example, what version of the software does not exhibit the
      problem?  Indicate if the solution is accepted by the community,
      one of several solutions pending agreement, or open possibly with
      experimental solutions.

   Workaround
      Practical workaround if no solution is available or usable.  The
      workaround should have sufficient detail for someone experiencing
      the problem to get around it.

   References
      References to related information in technical publications or on
      the web.  Where can someone interested in learning more go to find
      out more about this problem, its solution, or workarounds?

   Contact
      Contact name and email address of the person who supplied the
      information for this section.  The editors are listed as contacts
      for anonymous submissions.

2. Known Problems

   The remaining sections of this document present the currently
   documented known problems.  The problems are ordered by
   classification and significance.  Issues with protocol specification
   or architecture are first, followed by implementation issues.  Issues
   of high significance are first, followed by lower significance.

   Some of the problems initially identified in the previous versions of
   this document have been moved to Appendix A since they discuss issues
   where resolution primarily involves education rather than protocol
   work.

   A full list of the problems is available in the table of contents.







Cooper & Dilley              Informational                      [Page 4]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


2.1 Known Specification Problems

2.1.1 Vary header is underspecified and/or misleading

   Name
      The "Vary" header is underspecified and/or misleading

   Classification
      Specification

   Description
      The Vary header in HTTP/1.1 was designed to allow a caching proxy
      to safely cache responses even if the server's choice of variants
      is not entirely understood.  As RFC 2616 says:

         The Vary header field can be used to express the parameters the
         server uses to select a representation that is subject to
         server-driven negotiation.

      One might expect that this mechanism is useful in general for
      extensions that change the response message based on some aspects
      of the request.  However, that is not true.

      During the design of the HTTP delta encoding specification[9] it
      was realized that an HTTP/1.1 proxy that does not understand delta
      encoding might cache a delta-encoded response and then later
      deliver it to a non-delta-capable client, unless the extension
      included some mechanism to prevent this.  Initially, it was
      thought that Vary would suffice, but the following scenario proves
      this wrong.

      NOTE: It is likely that other scenarios exhibiting the same basic
      problem with "Vary" could be devised, without reference to delta
      encoding.  This is simply a concrete scenario used to explain the
      problem.

      A complete description of the IM and A-IM headers may be found in
      the "Delta encoding in HTTP" specification.  For the purpose of
      this problem description, the relevant details are:

      1. The concept of an "instance manipulation" is introduced.  In
         some ways, this is similar to a content-coding, but there are
         differences.  One example of an instance manipulation name is
         "vcdiff".

      2. A client signals its willingness to accept one or more
         instance-manipulations using the A-IM header.




Cooper & Dilley              Informational                      [Page 5]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


      3. A server indicates which instance-manipulations are used to
         encode the body of a response using the IM header.

      4. Existing implementations will ignore the A-IM and IM headers,
         following the usual HTTP rules for handling unknown headers.

      5. Responses encoded with an instance-manipulation are sent using
         the (proposed) 226 status code, "IM Used".

      6. In response to a conditional request that carries an IM header,
         if the request-URI has been modified then a server may transmit
         a compact encoding of the modifications using a delta-encoding
         instead of a status-200 response.  The encoded response cannot
         be understood by an implementation that does not support delta
         encodings.

      This summary omits many details.

      Suppose client A sends this request via proxy P:

         GET http://example.com/foo.html HTTP/1.1
         Host: example.com
         If-None-Match: "abc"
         A-IM: vcdiff

      and the origin server returns, via P, this response:

         HTTP/1.1 226 IM Used
         Etag: "def"
         Date: Wed, 19 Apr 2000 18:46:13 GMT
         IM: vcdiff
         Cache-Control: max-age-60
         Vary: A-IM, If-None-Match

      the body of which is a delta-encoded response (it encodes the
      difference between the Etag "abc" instance of foo.html, and the
      "def" instance).  Assume that P stores this response in its cache,
      and that P does not understand the vcdiff encoding.

      Later, client B, also ignorant of delta-encoding, sends this
      request via P:

         GET http://example.com/foo.html HTTP/1.1
         Host: example.com

      What can P do now?  According to the specification for the Vary
      header in RFC2616,




Cooper & Dilley              Informational                      [Page 6]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


         The Vary field value indicates the set of request-header fields
         that fully determines, while the response is fresh, whether a
         cache is permitted to use the response to reply to a subsequent
         request without revalidation.

      Implicitly, however, the cache would be allowed to use the stored
      response in response to client B WITH "revalidation".  This is the
      potential bug.

      An obvious implementation of the proxy would send this request to
      test whether its cache entry is fresh (i.e., to revalidate the
      entry):

         GET /foo.html HTTP/1.1
         Host: example.com
         If-None-Match: "def"

      That is, the proxy simply forwards the new request, after doing
      the usual transformation on the URL and tacking on the "obvious"
      If-None-Match header.

      If the origin server's Etag for the current instance is still
      "def", it would naturally respond:

         HTTP/1.1 304 Not Modified
         Etag: "def"
         Date: Wed, 19 Apr 2000 18:46:14 GMT

      thus telling the proxy P that it can use its stored response.  But
      this cache response actually involves a delta-encoding that would
      not be sensible to client B, signaled by a header field that would
      be ignored by B, and so the client displays garbage.

      The problem here is that the original request (from client A)
      generated a response that is not sensible to client B, not merely
      one that is not "the appropriate representation" (as the result of
      server-driven negotiation).

      One might argue that the proxy P shouldn't be storing status-226
      responses in the first place.  True in theory, perhaps, but
      unfortunately RFC2616, section 13.4, says:

         A response received with any [status code other than 200, 203,
         206, 300, 301 or 410] MUST NOT be returned in a reply to a
         subsequent request unless there are cache-control directives or
         another header(s) that explicitly allow it.  For example, these





Cooper & Dilley              Informational                      [Page 7]

RFC 3143           Known HTTP Proxy/Caching Problems           June 2001


         include the following: an Expires header (section 14.21); a
         "max-age", "s-maxage", "must-revalidate", "proxy-revalidate",
         "public" or "private" cache-control directive (section 14.9).

      In other words, the specification allows caching of responses with
      yet-to-be-defined status codes if the response carries a plausible
      Cache-Control directive.  So unless we ban servers implementing
      this kind of extension from using these Cache-Control directives
      at all, the Vary header just won't work.

   Significance
      Medium

   Implications
      Certain plausible extensions to the HTTP/1.1 protocol might not
      interoperate correctly with older HTTP/1.1 caches, if the
      extensions depend on an interpretation of Vary that is not the
      same as is used by the cache implementer.

      This would have the effect either of causing hard-to-debug cache
      transparency failures, or of discouraging the deployment of such
      extensions, or of encouraging the implementers of such extensions
      to disable caching entirely.

   Indications
      The problem is visible when hand-simulating plausible message
      exchanges, especially when using the proposed delta encoding
      extension.  It probably has not been visible in practice yet.

   Solution(s)

      1. Section 13.4 of the HTTP/1.1 specification should probably be
         changed to prohibit caching of responses with status codes that
         the cache doesn't understand, whether or not they include
         Expires headers and the like.  (It might require some care to
         define what "understands" means, leaving room for future
         extensions with new status codes.)  The behavior in this case
         needs to be defined as equivalent to "Cache-Control:  no-store"
         rather than "no-cache", since the latter allows revalidation.

         Possibly the specification of Vary should require that it be
         treated as "Cache-Control:  no-store" whenever the status code
         is unknown - that should solve the problem in the scenario
         given here.